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(57) Abstract 

A system for controlling a medium of exchange comprising: plural terminals at various locations for detecting the presence of a 
person and of an activity carried out by the person, and for providing signals indicative of the identity of the person and of the activity, 
a first database for storing predetermined exchange values for the activity, a second database for storing separate medium of exchange 
accounts for various persons including at least one of customers and merchants, apparatus for detecting the signals, for accessing the first 
database and for crediting an exchange value related to the activity to an account of a person carrying out the activity or on whose behalf 
the activity was carried out, in the second database, and an administration terminal in communication with the first database for generating 
and downloading to the first database parameters indicative of the predetermined exchange values for various activities, from time to time. 
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AMUSEMENT AND PREMIUMS NETWORK 

FIEW QF THE INVENTION 

This invention relates to the field of data 
communications, and in particular to a method and a 
system for on-line global distribution and redemption of 
loyalty points and coupons, control of directed 
advertising and control of parameters related to various 
operations, activity software, etc. 
PACKGRQUND TQ THE INVENTION 

Electronic transaction processing and awarding of 
loyalty points by bank card issuers, airlines, etc. have 
come into widespread use. For example, retailers 
commonly use card swipe terminals which read information 
stored on a magnetic stripe carried by the card. The 
information is received by telephone line at an 
administration office, where a computer checks the credit 
of the customer identified by the information from a 
database, and provides an authorization number or denial 
of the transaction. Because credit is to be provided by 
the issuer of the card, such as a bank, the transaction 
is associated specifically with and is controlled by the 
issuer of the credit card. 

As another example, when a debit card of a 
customer is swiped, a transaction value is keyed in by 
the retailer, and a PIN number is additionally keyed in 
by a user. The bank account of the user, the identity of 
which having been previously stored in association with 
the PIN number and card number, is accessed, and the 
transaction value is debited from the bank account of the 
customer. This amount (less a transaction charge) is 
credited to the bank account of the merchant identified 
when the debit card reader dials an administration office 
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which is in association with the bank. In this case as 
well, the transaction is associated specifically with and 
is controlled by the issuer of the debit card. 

It is common that some credit card issuers record 

5 loyalty points, for example a point for each dollar 
purchased on the credit card. These points are 
accumulated by the credit card issuer to the credit of 
the credit card user, and can be redeemed for merchandise 
or services typically advertised in a catalogue. In some 

10 cases, loyalty points are awarded by a vendor such as an 
airline, wherein the loyalty points can be used for 
airline travel with that airline. The vendor retains its 
own database of loyalty points accumulated against 
particular customers which have joined the loyalty point 

15 program. 

In addition, identity cards rather than credit 
cards are sometimes used in the awarding of airline miles 
based on purchases from certain vendors. In this case as 
well, the card issuer retains a single database of 

20 airline points against customers. 

In all such cases, the card issuer or the vendor 
(e.g. the airline) retains a simple database to keep 
track of the value of points accumulated or retained 
after redemption. 

25 There is a single authority which has issued the 

card, and tie-ins of a single card with a limited number 
(often only one, and in some cases a large number) of 
merchants. For example, a card issuer may have a tie-in 
with several merchants to provide a discount on 

30 merchandise or services. In such a case, no loyalty 

points tied to a particular merchant are awarded to the 
customer for patronizing the merchant, but loyalty points 
are awarded based on use of the card per se. 
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Further, the systems are not capable of dispensing 
or redeeming premiums or loyalty points "on-the-spot" for 
certain actions taken by customers, for example for 
patronizing certain merchants. Thus in this case as 

5 well, a single loyalty point database is associated with 
the card issuer, but not with the merchants. A merchant 
has no way of knowing whether a particular customer 
repeatedly purchases from that merchant* 

In other words, such systems provide and record 

10 loyalty points related to use of a card, or to a single 
merchant, or to a single program (such as airline 
points) , but do not provide loyalty points that can be 
traded between merchants or programs, and do not give 
incentive to patronize particular merchants as distinct 

25 from incentive to use a single card. The airline J points 
programs which are not associated with a particular 
credit card also require the use of a single card, and 
loyalty points cannot be traded between merchants . 

The systems are also not capable of accumulating 

20 prize values or loyalty points won on games played on 

game terminals, nor of dispensing prizes to players, e.g. 
loyalty points, premiums or plays on the games. 

The systems are not capable of displaying 
advertising directed to specific customers who have 

25 identified themselves or have been identified at a 

terminal or to classes of such customers, nor of tracking 
what advertising has been displayed to particular 
customers, nor for controlling what advertising should be 
shown to such identified customers or classes of 

30 customers . 

Neither are the systems capable of allowing the 
loyalty points won or otherwise acquired to be used as a 
medium of exchange between member merchants, e.g. 
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exchanging points won playing a video game for premiums 
which can be redeemed for goods or services by various 
merchants . 

SUMMARY OF THE INVENTION 
5 The present invention is an integrated on-line 

system which can accumulate and decrement exchange values 
associated with any customer from any merchant which has 
authorized access to the system or by an administrator or 
by plural authorized administrators. The system provides 
10 means for the awarded exchange values for any transaction 
to be controlled by an administrator or by authorized 
plural administrators, and can in addition be varied by 
location of the customer, by customer activity, by time 
and/or date, and by past history of either the activity 
15 itself or of the actions of the customer or of changing 
demographics of the customer . 

In addition, the system provides means for the 
administrator to vary the characteristics of a software 
program the customer, merchant, etc. is interacting with, 
20 so that loyalty points, advertisements, premiums, scores, 
game difficulty, characteristics of a game and reward 
brackets, pricing by currency and/or loyalty point 
exchange, etc. can be controlled and varied. The program 
can involve scoring of' sporting events, scoring of school 
25 tests, operate applications such as email, etc. or it can 
be a video game such as one operating in a system of the 
type described in U.S. patent 5,083,271 issued January 
21, 1992, or on a personal or public computer (public 
PC) . A user interface to the program can be displayed on 
30 a video terminal which can be one of the games described 
in the aforenoted U.S. patent, or on a personal or public 
computer, a display type or video telephone, a network 
computer interacting and communicating via a private 
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network, the internet, cable or the equivalent, a 
telephone line, etc. The advertisement can be shown in 
one or more frames (windows) which share the display with 
a game frame, or can occupy the entire display area* The 

5 advertisement can be directed to a particular player, or 
to a class of customer to which the player belongs, 
and/or can be scheduled based on time and/or date and/or 
location at which it is to be presented. The 
advertisement can be changed based on various criteria, 

10 such as the location of the display, how many times the 
advertisement has been run, how many times the 
advertisement has been directed to the customer or class 
of customer at a particular display or display location 
or at a class of locations or at plural particular or 

25 classes of locations or based on advertisements which 
have been shown to the customer in the past. Loyalty 
points (i.e. exchange values, which can include coupons, 
etc.) can be awarded based on an activity of the customer 
at least partly on the basis of his exposure to certain 

20 advertisements which may be displayed on the aforenoted 
displays . 

Game programs can be changed and varied as to 
degree of difficulty and currency or exchange value price 
to participate, competition brackets can be set up and 

25 varied, thresholds for prizes can be established and 

varied, prize and premium values can be accumulated for 
various activities such as plays, purchases, loyalty, 
and/or timing, customers or players can be authorized or 
disqualified, advertising can be directed to certain 

30 customers or classes of customers, premiums can be 

accumulated and dispensed and prizes awarded across any 
kind of commercial or non-commercial activity with 
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controllable interchangeability, preferably from an 
administration terminal . 

As an example, a customer can receive a coupon at 
a gasbar (or can read an announcement in a newspaper) 

5 containing a question to be answered, and if answered 

correctly at a terminal used in the system of the present 
invention, a prize (e.g. a coupon for $1000 off the price 
of a purchase, or the awarding of loyalty points which 
can be exchanged for merchandise or service at 

10 participating or at all merchants) can be awarded by the 
system, and the accounts of the customer, merchants and 
administrator incremented or decremented as required. 

The present invention thus provides for the first 
time an efficient way of combining loyalty point and 

15 premiums of any (rather than restricted) merchants, 

allows interchange of loyalty points, and at the same 
time gathers activity information and/or demographic 
information about the customers of those merchants as an 
effective commercial measurement tool, and so that 

20 advertising may be targeted and efficiently delivered to 
those exact customers which can best benefit from the 
advertising and those exact customers desired by the 
advertisers . 

By the use of the term merchants, included are 

25 merchants not only of merchandise, but also of services 
including the services of play of various games and 
contests . 

In this specification, the term customer and 
subscriber will be used synonymously, since a customer 
30 which has been registered into the system becomes a 

subscriber, and it is the registered customer which can 
accumulate loyalty points. 
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In accordance with an embodiment of the present 
invention, a system for controlling a medium of exchange 
comprises : 

(a) plural terminals at various locations for 

5 detecting the presence of a person and of an activity 
carried out by the person, and for providing signals 
indicative of the identity of the person and of the 
activity, 

(b) a first database for storing predetermined 
10 exchange values for the activity, 

(c) a second database for storing separate medium of 
exchange accounts for various persons (which can include 
either or both of customers and merchants), 

(d) apparatus for detecting said signals, for 
15 accessing the first database and for crediting an 

exchange value related to the activity to an account of a 
person carrying out the activity or on whose behalf the 
activity was carried out, in the second database, and 

(e) an administration terminal in communication with 
20 the first database for generating and downloading to the 

first database parameters indicative of the predetermined 
exchange values for various activities, from time to 
time . 

In accordance with another embodiment, a system 
25 for controlling a medium of exchange comprises: 

(a) terminals for determining the presence of a 
person, and of an activity carried out by the person, 

(b) display apparatus located adjacent to the 
terminal, 

30 (c) a regional server in communication with the 

terminals and display apparatus, 

(d) a first database accessible by the regional 

server, 
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(e) a support server in communication with the 
regional server, 

(f) an administration terminal on which control 
parameters can be input, 

5 (g) apparatus for receiving control parameters 

relating to medium of exchange values for activities 
carried out by the person from the administration 
terminal and for downloading the control parameters to 
the support server, 

10 (h) apparatus for transferring those control 

parameters which relate to media of exchange functions 
controlled by the regional server, to the first database, 
and 

(i) apparatus for transferring those . control 

15 parameters which relate to functions carried out at the 

display apparatus and the terminals, from the first 

database to control apparatus for the display apparatus, 
whereby the presence and activity of said person 

can be determined and messages can be controlled to be 
20 presented on the display apparatus directed to the 

identified person of class of person, and exchange values 

credited to the person. 

In accordance with another embodiment, a system 

for controlling a medium of exchange comprises: 
25 (a) plural terminals at various locations for 

detecting the presence of a person and of an activity 

carried out by the person, and for providing signals 

indicative of at least the activity, 

(b) a first database for storing predetermined 
30 demographic information related to the activity, 

(c) apparatus for detecting the signals, for accessing 
the first database and for storing data related to the 
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activity in a record related to a class of persons 
carrying out the activity, in the second database, and 
(e) an administration terminal in communication with 

the first database for receiving the stored data, and for 

5 generating and downloading to the first database 

parameters controlling the provision of offers to persons 
of the same class from time to time . 

In accordance with another embodiment/ a system 
for controlling a medium of exchange comprises: 

10 (a) plural terminals at various locations for 

detecting the presence of a person and of an activity 
carried out by the person, and for providing signals 
indicative of at least the activity, 

(b) a first database for storing predetermined 
25 demographic information related to the activity, 

(c) apparatus for detecting said signals, for 
accessing the first database and for storing data related 
to the activity in a record related to a class of persons 
carrying out the activity, in the second database, 

20 (e) an administration terminal in communication with 

the first database for receiving the stored data, and for 
generating and downloading to the first database 
parameters for controlling the provision of advertising, 
for display on display apparatus which is part of the 

25 terminal or is adjacent the terminal, to the person or to 
persons of the same class, or for controlling the 
printing of premiums on a printer which is part of the 
terminal or is adjacent the terminal, from time to time, 
RRTKF DESCRIPTION OF THE DRAWINGS 

30 A better understanding of the invention will be 

obtained by a consideration of the detailed description 
below, in conjunction with the following drawings, in 
which: 
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Figure 1 is a block diagram of a preferred 
embodiment of a system on which the present invention can 
be implemented, 

Figure 2 is a flow chart of call initialization 
5 and loyalty point or coupon data interchange, 

Figure 3 is a histogram of player scores against 
number of plays, 

Figure 4 is an illustration of a database format 
for specifying advertisements to be played under various 
10 circumstances , and 

Figure 5 is an illustration of an exclusion code 

signal . 

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION 

U.S. Patent 5,083,271 is incorporated herein by 
IS reference. This patent describes plural game arcades 
which are in communication with a central computer, or 
with one of plural regional computers which communicate 
. with a central computer. The regional computers receive 
game score data and compute tournament winners, 
20 downloading both winner information and advertising to 
local games at the game arcades. 

Turning to Figure 1, in place of the regional 
computers, regional servers 1A, 1B...1N, etc. are used. 
Each regional server is located at a separate regional 
25 data center, although for convenience of illustration 
they are all shown in this Figure in data center 3. 

Each regional server has a memory containing a r , 
corresponding database 5A, 5B...5N coupled to it . In the 
aforenoted patent, the corresponding memory stores not 
30 only score data, but also values of money on deposit to 
be credited against the playing of a game, and handicaps 
of players and/or games. If an activity other than 
playing a game is to be rewarded, the user activity can 
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similarly be handicapped (for example, awarding of 
variable numbers of points for use of a particular long 
distance telephone supplier) . In accordance with an 
embodiment of the invention, the databases 5A, 5B...5N also 
5 store specialized data relating to parameters used in a 
game or activity, such as difficulty levels, points to be 
awarded for certain game activities, and other functions 
to be described in more detail below, as well as 
parameters and content relating to advertising, premiums, 
10 loyalty points, etc. 

The data to be stored in databases 5A...5N is loaded 
by a decision support server 7, from data stored in a 
database 9 with which it communicates. 

Validation and redemption terminals 11 are in 
15 communication with the regional servers 1A...1N. Each of 
the terminals 11 is comprised of a card reader 13 and 
preferably a bar code reader 14, smart card reader, or 
the equivalent, coupled to a printer 15. The card reader 
is preferably also a card writer for writing the magnetic 
20 stripe on a card and/or for updating, debiting or 

crediting one or more values stored on a smart card (a 
card which carries a processor or the equivalent and a 
memory) . The term card reader is used in a general 
sense, since it can include a keypad or keyboard which 
25 can be used by the customer and/or merchant. The 

customer can also or alternatively be identified by a 
voice identifier, an eye iris reader, a fingerprint 
reader, a palmprint - reader , a keyed-in identity code such 
as a PIN number, etc. The printer is used to print 
30 receipts and coupons, preferably including a bar code or 
the equivalent. The card reader can be based on the type 
made by Verifone Corp. for swiping cards and dialing a 
credit or debit card administration office. 
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A terminal 11 should be located at the premises of 
each associated merchant authorized to use the system, 
and can be located at one or plural arcades 17 or other 
single or multi-terminal system. A system, which can be, 
5 but is not limited to arcade 17 which is similar to the 
system described in the aforenoted patent is in 
communication with a corresponding server, in a manner as 
will be described later. However, rather than each game 
19 communicating directly with a regional server via its 
10 own interface, it is preferred that it communicate with a 
regional server through a master game 21, via shell 
software which uses a particular communication protocol 
which can encrypt data. This will be described in more 
detail later. A database 23 is also coupled to the 
15 master game 21 . 

A computer 25, referred to below as a public PC 
25, can be in communication with an associated regional 
server 1A...1N. Preferably a card reader 13, bar code 
reader 14 and printer 15 are coupled to the computer, as 
20 well as a display 27, keyboard 28, game controls (e.g. a 
joystick, mouse, trackball, pedals, etc.) a CD ROM player 
29, and a DVD (digital versatile disk) player 31. 

An administration office 41 contains a computer 
terminal 43 preferably operating in a Windows trn software 
25 environment, with a display 45. Rather than a Windows tm 

software environment, any type of operating system can be 
used, such as one which will operate under control of 
applets downloaded from the internet or any other 
network, Macintosh, OS/2, etc. The terminal 43 includes 
30 a database and a processor for controlling parameters of 
software used in the system, and can communicate with the 
decision support server 7 as will be described below. 
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In operation, games, advertising and parameters 
relating to loyalty points and/or coupons are downloaded 
under control of the decision support server 7 to 
database 9, then are distributed to regional servers 

5 1A...1N, then are downloaded to database 23. Alternatively 
the games, parameters and/or advertising are stored at 
the arcade 17 on local mass storage devices such as hard 
disk drives, digital versatile disks (DVDs) or CD ROMs 
(or can be stored in a semiconductor or any other form of 

10 mass storage memory) / and are enabled from data stored in 
the decision support server 7 and preferably downloaded 
to the database 23. The games, parameters and/or 
advertising can be provided via applet if desired. In 
the description below, and only for this example, the 

15 games and advertising will be described as being stored 
on DVDs (in database 23) at the arcade. The database 
will be considered for this example to be a combination 
of the local mass storage and semiconductor memory, but 
it should be understood that the data can alternatively 

20 be downloaded from database 5A to 5N coupled to the 
regional server, and stored for use as needed in the 
database 23. 

It is preferred that the games themselves should 
be written within a shell, with software "hooks" between 

25 the games and shell. The shell should be responsible for 
starting and stopping the game, altering its parameters, 
controlling the display of the game that is to be played, 
and communicating both with other games and with the 
regional server 1A...1N. It is preferred that each of the 

30 games should communicate with the regional server only 
under control of the master game 21. The software 
operated by the master game 21 should in addition be 
designed to communicate with each of the games of the 
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arcade, and with a designated regional server using a 
communications manager program, in accordance with a 
predetermined protocol . 

Customer accounts are retained in the database 9, 
5 and are preferably comprised of the following fields: 

1. Account data (customer name and PIN), 

2. Balance of account (in currency), both current 
balance and pending balance (the latter being the 
expected balance after an ongoing transaction has been 

10 completed) , 

3. The identity and value of coupons and premiums 
allocated to the customer, 

4. The balance value of loyalty points associated 
with the customer, e.g. as incremented or decremented by 

15 a device such as by an input device at a merchant 

location (for example by inputting via a keypad connected 
to the card reader 13 at a validation and redemption 
terminal 11) or by an administrator via terminal 43 at 
the administration location 41, or by operating an 

20 automatic terminal such as a coin telephone having a 

swipe card reader in administrative communication with 
regional server 1A to IN, a game machine, etc., 

5. Game ratings, such as skill level of the customer 
for variously played games, handicap values of the 

25 customer for variously played games, profiles (e.g. how 
much time is allocated to the player to complete various 
games) , 

6. Viewing history of advertising (e.g. a record of 
the most recent time that the customer has viewed a 

30 particular advertisement) , 

7. Images displayed for this customer, 

8. The identities of identification cards issued to 
the player, 
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9. Merchandise orders, e.g. the identity and loyalty 
point, premium or currency cost of merchandise that has 
been ordered, the date ordered, the date the order was 
sent to the supplier, the date the order was shipped, 

5 etc., 

10. The game play history, e.g. for each game played, 
the rank achieved, number of players in a game or 
tournament , etc . , 

11. Data regarding membership of the customer in 
10 competitions or teams, 

12. Records of payments of fees made by the customer, 
and 

13. Records of customer premiums and/or prizes awarded 
(which can be used e.g. for tax computation) 

25 The administrator characterizes each game and 

activity relating to merchant products and services with 
certain parameters, and downloads these parameters from 
terminal 43 to server 7. For example;, the administrator 
establishes game formulae for each game, loyalty points 
20 (or none) for playing each game, for patronizing 
particular merchants, etc. 

When a customer is issued an identity (ID) card, a 
PIN number is issued in a well known manner, and 
information re its issuance is uploaded from a validation 
25 terminal 11 to the associated regional server 1A to IN. 
A record in the database 9 relating to this customer is 
established by server 7. The record is seeded by the 
parameters provided by the administration terminal to the 
server 7. For example, upon first initiation of the 
30 record, a number of loyalty points can be deposited to 
the customer, and recorded in the database in field 4. 

The customer then pays currency to play say, 5 
video games. The payment value is entered by swiping the 
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ID card in a local card reader in the arcade, and by then 
entering the PIN number of the customer and the number of 
games to be played, or a currency amount into a local 
keypad. This amount is stored (deposited) in database 
5 field 1 (see the above field list) of database 9, after 
uploading from the arcade 17 via master game 21. 

The customer then goes to the game and swipes his 
card in a card reader associated with the game. The 
request to initiate the game is sent to the game from the 
card reader, and value of the game play is sent to the 
decision support server 7. Server 7 addresses database 
9, and selects the record of the customer from the card 
number read and provisionally decrements the amount on 
deposit, storing the resulting pending balance. If the 
game is not played (e.g. if there is a power outage), the 
pending balance is again incremented back to the previous 
balance after a predetermined amount of time. By using a 
central decision support server 7 and database 9 to store 
the customer accounts, the customer can be provided with 
service at any location which communicates with any 
regional server. A duplicate account is established and 
retained in the regional support server database 5A...5N, 
the records being mutually updated (synchronized) from 
time to time. 

At the time of establishment of the record in 
database e.g. 5A, the server 7 would also store values in 
the remaining fields of the record. For example, it 
would store an advertisement value, to be described in 
more detail below, in field 6, indicating that no ads 
have been presented to the customer. 

After the customer has swiped his card at a game, 
and thus identifies himself, the local database provides 
a data message to a the local system which enables the 
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selected game. If it is the first time the customer has 
identified himself to the local system, the regional 
server e.g. 1A sends a data message which enables the 
selected game. It also enables a DVD to run an 
5 advertisement to the game via its shell, which overlays 
the game in a window, or is presented prior to or with 
the initial, intermediate or final screens of the game. 
For example, the initial screen can be a "welcome to a 
new player" screen, with an advertisement relating to one 
10 or another of the associated merchants. The 

advertisements to be run are pre-established at the 
administration terminal 43. 

The fact of running a particular advertisement and 
of the customer being located at a particular game 
15 (determined from his ID card) is then stored in the 10 th 
field of the record. When the game has been completed, 
the score is uploaded to the regional server and the rank 
of the player is established and is stored in the 10 th 
field. The number of plays of the player of that game, 
20 and of other games, are also stored in the 10 th field. On 
the basis of this, depending on the administrator, 
loyalty points, coupons or premiums can be provided to 
the customer. 

For example, if the customer has achieved a 
25 particular score, a predetermined number of loyalty 

points can be awarded, and added to those in the balance 
in the 4 th field of the database record. A printer 15 can 
dispense a coupon to the customer e.g. for a discount on 
a food item at a fast food outlet, the serial number and 
30 value of which is recorded in the 3 rd field of the record. 
The printout can also record the score and the game that 
was played. 
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The identity of the advertisement which was run is 
recorded in the 6 th field of the record. 

The customer in achieving a particular amount of 
expertise can be handicapped by the software in the 
5 regional server 1A, and the handicap value recorded in 

the 5 th field of the record, the rank achieved recorded in 
the 10 th field, and all of this information can be printed 
on the same ticket as the coupon, or another ticket. 

Now assume that the player attends a different 
10 arcade, and wishes to play a game. He will swipe his ID 
card in the local card reader, press a button to command 
the start of or the identity of the game if necessary, 
and his identity, a command to play a game and the cost 
to play is uploaded to the associated regional server, 
15 say server IB. Server IB searches its database 5B for a 
record of the identified customer, and doesn't find it. 
It then sends an inquiry to the server 7, which sends an 
inquiry to each of the other regional servers. Server 1A 
responds, and provides an indication to server IB that 
20 the customer record is stored in a database associated 
with server 1A. 

Server 1A then sends the record of the customer to 
server IB via server 7 . Server IB checks whether the 
second field has sufficient balance to pay for the game. 
25 On the indication that it does, a provisional decrement 
is done as described earlier, and server IB sends a 
signal to the master game of the arcade to enable the 
game . 

The server IB also checks the ad view history and 
30 image last viewed, and enables the DVD at the arcade to 
run the next advertisement in the predetermined sequence 
of advertisements to the game to be played, via the game 
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shell. The entire process is repeated as described 
earlier . 

In the event the customer has used the local 
system before, and his identity data, etc. is stored in 
5 the local database, the above process can be carried out 
using the data stored in the local database, rather than 
using the data stored in the server. 

The score can result in loyalty points or premiums 
being awarded to the player, which are stored in the 
10 account of the player. 

Assume now that the customer wishes to redeem 
loyalty points or premiums. The customer can visit a 
validation and redemption terminal, which can be at the 
location of a merchant, a public PC, or at an arcade. 
IS The ID card of the customer is read, and an attendant 
types in a request on a local keyboard such as 28 to 
obtain the number of loyalty points, or the identities of 
coupons or premiums held by the customer. This request 
is uploaded to the regional server, which reads the 
20 database e.g. 5A and accesses the record of the customer 
identified by the card (and PIN number, if desired) . On 
verification by the regional server, the data stored in 
the fields of the information requested by the attendant 
are then downloaded to the local terminal, such as 
25 computer 25, and is displayed on display 27. 

The customer can ask for redemption of the value 
of the coupon. For example, if the validation and 
redemption center is at a fast food outlet, and the 
coupon is for a discount on a hamburger from the fast 
30 food outlet, the merchant can sell the hamburger at the 

required discount, take the coupon from the customer, and 
key in the coupon on a keypad or read a barcode or 
magnetic stripe or the equivalent carried by the coupon, 
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to identify it and record it as having been redeemed. 
The local computer or the equivalent then uploads this 
data to the regional server 1A, which records that the 
coupon has been rendered. 

While this transaction is going on, there could be 
a display adjacent the redemption equipment. The 
regional server, in learning of the presence of the 
customer at that location from the ID card swipe, can 
then look up the advertisement viewing history from the 
6 th field of the customer's record in the database, and 
send a control signal to the computer or the equivalent 
at the redemption center, to enable a local DVD 31 to run 
the next advertisement in a predetermined sequence to the 
display which is adjacent the customer. Loyalty points 
can be awarded to the identified customer based on 
viewing a particular advertisement, and stored in the 
database as described earlier. 

In a similar manner, loyalty points can be 
redeemed. The customer can attend a redemption center 
which can be a merchant, or a special catalog store. 
After swiping the ID card of the customer and keying in a 
request to display the number of loyalty points accrued 
to the customer, the regional server e.g. 1A accesses the 
record of the customer using his ID and PIN number in 
database e.g. 5A, and downloads the information to a 
local display. Following redemption of a particular 
number of loyalty points for the merchandise or services 
requested, the 4 th field of the record of the customer is 
decremented by the value of the loyalty points redeemed. 

It should be noted that the system is global, in 
that any merchant can have a redemption terminal. Upon 
redeeming loyalty points which have been accrued by the 
customer by playing games, viewing advertisements, or 
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using services of other merchants, etc, the redeeming 
merchant can be owed a certain value based on the 
redemption. This value or the equivalent in loyalty 
points, can be stored (credited) in a database 5A related 
5 to the merchant. When a customer purchases goods from 
that merchant, a certain number of loyalty points can be 
awarded the customer, and the balance debited from the 
balance of the merchant. Administrator service fees in 
the form of loyalty points can be accrued to an account 
10 of the administrator for each transaction. In this 

manner, loyalty points become a medium of exchange for 
the customer, the merchants and the administrator. 
Loyalty points or a monetary amount can be 
decremented from an account of each merchant for each 
15 play of its advertisement. 

At the end of a predetermined period, for example 
quarterly, yearly, etc., the administrator and merchants 
can settle the accounts, e.g. collecting a prescribed 
monetary value for negative balances of merchant loyalty 
20 point accounts, and paying a prescribed monetary value 

for positive balances of merchant loyalty point accounts. 

Loyalty points can also be redeemed by the 
customer for any merchandise or service at any merchant 
location or venue at which a service terminal is located, 
25 or for game play at an arcade. 

Two types of data interchange are preferably used 
in the system: synchronous and asynchronous. In 
synchronous interchanges, the client initiates a 
connection to a server, sends a request, and await a 
30 reply, in a manner similar to credit card authorizations 
in retail stores. An example of this type of interchange 
in the present invention is the validation of a prize 
receipt. Asynchronous interchanges are used for database 
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synchronization. They allow events that have been queued 
by clients to be sent to servers, and allow servers to 
add or update information in a client's database. 

Four modes of communication between clients and 
5 servers are preferred to be used: 

- Queries from clients to servers for specific 
information, 

- Events being transmitted from clients to 

servers, 

10 - Record and file system synchronization 

transmitted from servers to clients, and 

- Interactive on-line traffic, allowing on-line 
services in which processing is done in real-time by the 
server, or through a proxy process on the server. 

IS Because of the short duration and unpredictability 

of query calls, they are preferably implemented with a 
point-of-sale, packet type transaction type network, with 
dial-in connections from various client locations using a 
global toll-free number. 
20 The remaining types of calls are more predictable 

in nature and duration, typically lasting one or more 
minutes, and preferably use full duplex stream-oriented 
communications. This can be implemented using a 
dedicated or non-dedicated dial-up line between client 
25 and server, using TCP/IP ports (internet or intranet) . 

Thus each server can initiate two types of 
connections to client servers: asynchronous dial-in to 
the transaction network at relatively low speeds (e.g. 
2400 baud or higher) for short duration queries, or via a 
30 dial-in PPP connection (e.g. 28.8 kbaud or higher) or 
ISDN to perform sockets-based communication. 

The data transmission protocol used is preferred 
to be bi-directional full-duplex asynchronous 
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communication using X.25-based packet switching, but 
other communications technologies, e.g. ADSL can be used, 
as they become widely available. Prior to application to 
the network, the event data should be packetized, 
5 inserted into variable length telecommunication packets, 
compressed and encrypted using the encryption key of the 
location. Other fields in the telecommunication packet 
need not be compressed or encrypted. The received 
packets should be decrypted, decompressed, and extracted 
10 from the telecommunication packets. 

The transmissions are preferably initiated from 
the transmitting entity (dial-in) rather than being 
polled. The calls can be normal (e.g. to pass data re 
start, game plays, alarms, meters, etc. to and from the 
IS client, stored in a queue at that location for subsequent 
transmission), urgent (e.g. such as customer information 
when a card is swiped), and receipt validation (e.g. to 
verify calls used by validation terminals) . 

Terminals communicating within a single location 
20 can use lObaseT twisted pair wiring and 802.3 (Ethernet tm ) 
standard for data link management, or higher speed 
Ethernet or other technologies, as they become available. 
The regional servers can accept connections from either 
the point-of-sale transaction network or from a TCP/IP 
25 internet/intranet connection (using Berkeley sockets) . 
The same application-layer protocols operate over each 
connection, with the possible exception of 
synchronization, which can operate only over TCP/IP 
connections, if desired. 
30 The four types of packets referred to above can 

have a number of subtypes, as follows: 
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Packet 
Type : 

Control 



Query 



Event 



Synchron- 
ization 



Possible Subtypes 



Acknowledgment (ACK) 

Context Negotiation 

Ping Response 

Close Query Link 

Close IP Link 

Link Status Response 

Suspend Processing Response 

Resume Processing Response 

Synchronize Response 

Test 

Receipt Validation 
Subscriber Information 
Account Withdrawal 
Account Deposit 
Subscriber Account Data 

Request 
Winning Redemption Play 
Subscriber ID Request 
Credit/Debit Request 
Save State Request 
Restore State Request 
New subscriber Card Request 
Reserve Merchandise 
Purchase Merchandise 
Release Merchandise 
Subscriber Ranking Request 

Alarm 

Redemption Play 
Ad Statistics 
Down Times 
New Team 

Loyalty Point Awards 
Inventory 

File Initial Download 
File Initial Upload 



Negative Acknowledgment (NAK) 
Ping 

Open Query Link 

Open IP Link 

Link Status Request 

Suspend Processing 

Resume Processing 

Synchronize 



Test Response 

Receipt Validation Response 
Subscriber Information Response 
Account Withdrawal Response 
Account Deposit Response 
Subscriber Account Data Response 

Winning Redemption Play Response 
Subscriber ID Response 
Credit/Debit Response 
Save State Response 
Restore State Response 
New Subscriber Card Response 
Reserve Merchandise Response 
Purchase Merchandise Response 
Release Merchandise Response 
Subscriber Ranking Response 

Tournament Play 
Meter Readings 
Service Accesses 
New Subscriber 
Issued Coupons 



Table Download 
File Next Download 
File Next Upload 



When a call is connected over the point of sale 
network or either of the TCP/IP ports, the client and 
server exchange context negotiation packets to configure 
the session communications as shown in Figure 2. When 
both parties have acknowledged the context negotiation, 
data packets can begin. 

The client sends a context negotiation packet with 
the settings it wishes to use for the call (including the 
encryption and compression parameters) . This packet also 
tells the server what type of call this is (e.g. events, 
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queries, etc.). The server examines the context 
negotiation packet and determines whether the values are 
acceptable. If so, it sends a context negotiation packet 
with the same settings to the client. The client 
5 acknowledges this packet to the server, and the call is 
considered to be established. 

If the server cannot use the context provided by 
the client, it sends its own context negotiation packet 
back to the client with its preferred settings (e.g. a 
10 "lower" standard for compression or encryption) . If the 
client agrees with these settings, it sends an 
acknowledgement to the server, and the call is considered 
to be established. 

The contents of the context packet are sent 
15 uncompressed, but encrypted using the terminal's 16 byte 
license key and a TEA encryption algorithm. The terminal 
cannot operate unless the license key entered at the 
machine matches the key entered through the server 
administrative application. 
20 If a device receives a context packet for an 

encryption method it can perform, it can NAK 
(unacknowlege) the packet. The server should retransmit 
session key packets, working from best to worst 
encryption (retrying a number of times in case of 
25 communications faults) until the client returns an 

acknowledgement. If the client never acknowledges the 
packet, the server should close the connection. 
Likewise, if the server never acknowledges the packet 
from the client, the client can close the connection. 
30 The client is free to retry with a new socket on the same 
call . 

When a connection is established over the 
asynchronous point of sale link, the client may 
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iinmediately begin transmitting data packets to the 
server. Then a PPP connection is established, the client 
should create a socket connection to one of the TCP ports 
listed above. Packets can then be sent over this socket 
5 connection. Multiple socket connections can be opened to 
allow parallel processing of synchronization, event and 
query traffic. 

Query exchanges preferably occur in lockstep over 
a single connection. When a terminal issues a query, it 
10 waits on the same connection for a matching query 

response to arrive. The terminal then processes the 
query response, sends an acknowledgement, then closes the 
connection or continues with other query exchanges . 

If a query initiates the download of table and/or 
15 file information to the client, the downloads should take 
place before the server sends the query response. When 
the query response is received at the client, it can 
assume that all downloads are complete. 

Event transfer from clients to servers follows a 
20 lockstep acknowledgement cycle in which the client sends 
event packets and the server sends acknowledgement or 
nonacknowledgement packets in response. Events should 
remain in the client's event queue until an 
acknowledgement has been received from the server. When 
25 all events have been sent and acknowledged, the client 
can close the connection. 

When a client makes a synchronization call, the 
client and server begin by exchanging inventory packets. 
The client sends an inventory of all data currently 
30 loaded, and the server sends an inventory of what the 

client should have (including table records and files) . 

The client should use the server's inventory to 
delete all records and files that are not present at the 
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server. The server should use the client's inventory to 
build a set of table and file download packets to send 
new information to the client . 

Once the inventories have been exchanged, the 

5 server should begin sending table and file download 

packets. The client should respond to these with either 
an acknowledgment or nonacknowledgement packet. When the 
server has sent all records, it should send a table 
download packet with 0 records to indicate the end of 

10 data. The client is free to close the connection at this 
point . 

All packets should be framed with a consistent 
header and trailer, to allow the protocol processor in 
the receiving server or terminal to distinguish between 
15 different versions of requests. A preferred packet is as 
follows : 



Of f set : Field 

Size: DESCRIPTION 

0 byte Packet type - the following values are 

defined: 

0x80 = Control packets 

0x81 = Query packets 

0x82 = Event packets 

0x8 3 = Synchronization packets 

Note that the high bit is used to 

distinguish these packets from earlier 

version packets. 

1 byte Subtype - the following values are 

defined: 

Control packets: 

0 = Acknowledgement 

1 = Negative Acknowledgement 

2 = Context Negotiation 

3 = Ping 

4 = Ping Response 

5 = Open Query Link 

6 = Close Query Link 

7 = Open IP Link 

8 = Close IP Link 
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9 = 


Request Link Status 


10 = 


Link Status Response 


11 = 


Suspend Processing 


12 = 


Suspend Processing Response 


13 = 


Resume Processing 


14 = 


Resume Processing Response 


15 = 


S vnchroni ze 


16 = 


Synchronize Response 


Query packets : 




0 = 


Test 


1 = 


Test Response 


2 = 


Receipt Validation 


3 = 


Receipt Validation Response 


4 = 


Customer Information 


5 = 


Customer Information Response 


6 = 


Account Withdrawal 


7 = 


Account Withdrawal Response 


8 = 


Account Deposit 


9 = 


Account Deposit Response 


10 = 


Customer Account Data Request 


11 = 


Customer Account Data Response 


12 = 


Winning Redemption 


13 = 


Winning Redemption Response 


14 = 


Customer ID Request 


15 = 


Customer ID Response 


16 = 


Credit Debit Request 


17 = 


Credit Debit Response 


18 = 


Save State Request 


19 = 


Save State Response 


20 = 


Restore State Request 


21 = 


Restore State Response 


22 = 


New Customer Card Request 


23 = 


New Customer Card Response 


24 = 


Reserve Merchandise 


25 = 


Reserve Merchandise Response 


26 - 


Purchase Merchandise 


27 = 


Purchase Merchandise Response 


28 = 


Release Merchandise 


29 = 


Release Merchandise Response 


30 = 


Customer Ranking Request 


31 = 


Customer Ranking Response 


Event packets: 


0 = 


Alarm 


1 = 


Tournament Play 


2 = 


Redemption Play 


3 = 


Meter Readings 


4 = 


Ad Statistics 


5 = 


Service Accesses 


6 = 


: Down Times 


7 = 


: New Customer 
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8 = New Team 

9 = Issued Coupons 

10 = Loyalty Point Awards 
Synchronization packets: 

0 = Inventory 

1 = Table Download 

2 = File Initial Download 

3 = File Next Download 

4 = File Initial Upload 

5 = File Next Upload 

2 2 bytes Packet size (in bytes, including the 
type, subtype, size and CRC fields) , 
LSB first 

4 N bytes Data (see individual packet descriptions 
for format) 
4+N 2 bytes CRC of packet 

Acknowledgement packets indicate the successful 
receipt of information. The total size of the framed 
packet will be 6 bytes 

Field Size: Description: 

1 byte Packet Type = 0x80 

1 byte Packet Subtype = 0x0 0 

2 bytes Packet size = 6 
2 bytes CRC 

Negative Acknowledgement (NAK) 

Negative Acknowledgement packets indicate that a 
transmission was unsuccessful or that the receiver 
encountered an error processing the data. The total size 
of the framed packet will be 7 bytes. 



Field Size: Description: 

1 byte Packet Type = 0x80 

1 byte Packet Subtype = 0x01 

2 bytes Packet Size = 7 

1 byte Failure Code 

0 Generic failure 

1 System error 

2 Allocation failure 

3 Invalid request 

4 Communications error 

2 bytes CRC 
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Context Negotiation 

Context Negotiation packets have the following 
data structure 

Field Size: Description: 

1 byte Packet Type = 0x80 

1 byte Packet Subtype = 0x02 

2 bytes Packet Size = 40+ 

4 bytes Location ID (LSB first) 

6 bytes Terminal ID 

[BEGIN ENCRYPTED AREA] 

16 bytes License Key 

1 byte Connection type 

1 byte Encryption type 

1 byte Transmission Sequencing 

2 bytes Key Length (in bytes, LSB first) 
N bytes Key Data 

(Pad encrypted area to even 8 byte boundary with zeros! 
[END ENCRYPTED AREA] 
2 bytes CRC 



Location ID will be 0 in packets from the client. 
It will be filled in with packets from the server with 
the location ID configured for the terminal ID from the 
client, or 0 if the terminal is not configured in any 

5 location. Terminals that are not configured in any 
location can still access the server for some limited 
functions. However, if the licensing information is not 
correct, the server will never send a Context Negotiation 
packet to the client. 

10 The license key is a value entered through the 

user interface at the terminal, and entered by the 
operator when configuring the machine in the 
administrative application. It is used to encrypt the 
encrypted area of the Context Negotiation packet. When 

15 the packet is received, the receiving node decrypts the 

encrypted area with its stored license key, then compares 
that key with the decrypted version from the packet. If 
the two do not match, the machine is not licensed 
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correctly and the Context Negotiation will not succeed 
until this is corrected. At the terminal/ a message 
indicating incorrect license information should be 
displayed or printed. At the server, the event will be 
5 logged for reporting and/or alarming. 



codes (0x80 through 0x83) indicating the type of 
connection being made. This will indicate to the server 
which protocol processor to launch for the connection. 

10 Note that if more than one type of activity needs to 

occur on one connection, the client can send a Context 
Negotiation packet during the call to renegotiate the 
call type (and other parameters of the connection as 
well) . When this occurs, all in-progress operations are 

15 completed, then renegotiation occurs. 



The connection type will be one of the packet type 



The Encryption type field will be one of the 



following values: 



Value Des crip ti on 



20 



0 No finrrvption 

1 XQR of kev and plain text 

2 Earlier Protocol Version encryption 

3 TEA (see Appendix A for algorithm) 

4 IDEA 

5 RSA 



25 



Transmission sequencing will be one of the values 



below: 



30 



Value 



0 



Description 

Lockstep (send packet, wait for Ack, 
send next packet) 



The contents of the key data will depend on the 
encryption type, as shown here: 
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Encryption 

Type Key Length and Key Data 

0 data will be included 

5 1 Key length will be 0, and no 

2 Key length and key data can vary 

3 Key length and kev data can vary 

4 Key length is 16, key data can vary 

5 Key length is 5, Key data can v^ry 
10 Key length and key data can vary 

For connections between terminals within a single 
location, or between processes on a single terminal, the 
terminal ID and location ID are both set to 0. The 
75 contents of the packet will not be encrypted and should 
have the following values: 

Encryption type = 0 

Transmission Sequencing = 0 

Key length =0 ^ 
20 This type of connection is only valid on LAN 

segments or between processes on a single machine. 

The license key field will be filled by the 
terminal's license key. This allows the server process 
to enforce unique license keys and prevent services from 
25 establishing their own connections to the server without 
their own valid license keys. 
Ping 

Ping packets are used to test communications to 
the server. The total size of the framed packet will be 
30 6 bytes. 

Field Size Description 

1 byte Packet Type = 0x80 

1 byte Packet Subtype = 0x03 

2 bytes Packet Size = 6 
35 2 bytes CRC 

Upon receipt of a Ping packet, the server will 
immediately generate a Ping Response packet and send it 
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to the client. This does not require any database or 
file system access, and can be used to test the basic 
connection between client and server processes. 
Ping Response 

5 Ping Response packets are sent in reply to a Ping 

packet. The total size of the framed packet will be 6 
bytes. * 

Field Size: Description: 

1 byte Packet Type = 0x80 

10 l byte Packet Subtype = 0x04 

2 bytes Packet Size = 6 
2 bytes CRC 

Open Query Link 

25 A request that a link to the server be created 

that is capable of supporting query traffic (or increases 
the reference count of an existing link) . The total size 
of the framed packet will be 6 bytes. 

Field Size: Description: 

20 1 byte Packet Type = 0x80 

1 byte Packet Subtype - 0x05 

2 bytes Packet size = 6 
2 bytes CRC 

25 This operation is intended for use between slave 

and master terminals within a location or between 
processes on a single terminal. On receipt of this 
packet, the recipient should establish a connection to 
the server suitable for query traffic- This may mean 

30 forwarding a similar request to the next higher server in 
the hierarchy. 

If there is already a link established, its 
reference count is incremented. 
Close Query Link 

35 a request that a link to the server established by 

an Open Query Link request be closed (or the reference 
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count of the link be decremented) . The total size of the 
framed packet will be 6 bytes. 

Field Size: Description: 

1 byte Packet Type = 0x80 

5 1 byte Packet Subtype = 0x06 

2 bytes Packet Size = 6 
2 bytes CRC 

Open IP Link 

10 A request that a link to the server be created 

that is capable of supporting IP traffic (or increases 
the reference count of an existing link) . The total size 
of the framed packet will be 6 bytes. 

Field Size: Description: 

25 1 byte Packet Type = 0x80 

1 byte Packet Subtype = 0x07 

2 bytes Packet Size = 6 
2 bytes CRC 

20 This operation is intended for use between slave 

and master terminals within a location or between 
processes on a single terminal. On receipt of this 
packet, the recipient should establish a connection to 
the server suitable for all types of traffic* This may 

25 mean forwarding a similar request to the next higher 
server in the hierarchy. 

If there is already a capable link established, 
its reference count is incremented. 
Close IP Link 

30 .A request that a link to the server established by 

an Open IP Link request be closed (or the reference count 
of the link be decremented) . The total size of the 
framed packet will be 6 bytes. 
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Field Size: 

1 byte 

1 byte 

2 bytes 
2 bytes 



35 

Description : 

Packet Type = 0x80 
Packet Subtype = 0x08 
Packet Size = 6 
CRC 



Request Link Status 

A request for the current link status, 
size of the framed packet will be 6 bytes. 
Field Size: Description: 



The total 



1 byte 

1 byte 

2 bytes 
2 bytes 



Packet Type = 0x80 

Packet Subtype = 0x09 

Packet Size = 6 
CRC 



When a server receives this request, it should 
respond with the status of the link to the main ADMIN 
server group. This may mean forwarding a similar request 
to the next higher server in the hierarchy. 
Link Status 

Returns the current link status. Sent in response 
to a Request Link Status packet. The total size of the 
framed packet will be 6 bytes. 



25 



Field Size: 



Description : 



30 



35 



40 



1 byte Packet Type = 0x80 

1 byte Packet Subtype = OxOA 

2 bytes Packet Size = 7 
1 byte Link Status 

Low order nibble is current link status: 

0x00 Link state unknown (indicates an error) 

0x01 Link is idle 

0x02 Connecting asynchronous 

0x03 Connecting asynchronous, IP request 

pending 
0x04 Connecting IP 
0x05 Connected asynchronous 

0x06 Connected asynchronous, IP request pending 
0x07 Connected IP 
High order nibble is modem state (if applicable) 
0x00 Modem idle (or no modem in link) 
0x10 Modem is dialing 
0x20 Modem is waiting for answer 
0x30 Modem is connected 
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0x40 Modem is authenticating 
High bit indicates processing is suspended 
0x80 Processing suspended 
1 byte Query status 
5 High bit is one if a query is in progress 

Bits 0-6 indicate the percentage complete 

1 byte Event status 

High bit is one if an event exchange is in progress 
Bits 0-6 indicate the percentage complete 
10 1 byte Synchronization status 

High bit is one if a database synchronization is in 
progress 

Bits 0-6 indicate the percentage complete 

2 bytes CRC 

15 

The fields in the response packet relating to 
query, event and synchronization status are relevant 
only when the server process is running on a master 
20 terminal within a location. All other servers will 
return 0 for these three fields. 
Suspend Processing 

Requests that the communications process on the 
master terminal suspend any activity that could impact 
25 system perf ormance . This prevents service degradation 
to ensure fair tournament play. The total size of the 
framed packet will be 10 bytes. 

Field Size: Description: 

1 byte Packet Type = 0x80 

30 l byte Packet Subtype = OxOB 

2 bytes Packet Size = 10 

4 bytes Time-out (seconds) 

2 bytes CRC 

35 

Suspend Processing Response 

Sent by the communications process on a master 
terminal in response to a Suspend Processing request 
packet, indicating that the processing will be 
40 suspended as soon as possible. The client can use Get 
Link Status to determine when processing has been 
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suspended. The total size of the framed packet will be 
6 bytes. 

Field Size: Description: 



1 byte 

1 byte 

2 bytes 
2 bytes 



Packet Type = 0x80 
Packet Subtype = OxOC 
Packet Size = 6 
CRC 



10 



15 



20 



Resume Processing 

Informs the communications process on a master 
terminal that normal processing can be resumed. This 
should be performed after a time-critical operation has 
completed, and should balance each Suspend Processing 
packet. The total size of the framed packet will be 6 



bytes . 



Field Size: 

1 byte 

1 byte 

2 bytes 
2 bytes 



Description : 

Packet Type = 0x80 
Packet Subtype = OxOD 
Packet Size = 6 
CRC 



25 



30 



35 



Resume Processing Response 

Sent by the communications process on a master 
terminal in response to a Resume Processing request 
packet, indicating that normal processing will be 
resumed. The total size of the framed packet will be 6 
bytes. 

Field Size: Description: 



1 byte 

1 byte 

2 bytes 
2 bytes 



Packet Type = 0x80 

Packet Subtype = OxOE 

Packet Size = 6 
CRC 



Synchronize 

Requests that the communications process on a 
master terminal initiate a synchronization with its 
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server. Different levels of synchronization can be 
requested in the flags field. Note that the 
communications process should perform a full 
synchronization on startup and again every few hours 
5 automatically (depending on the dialing interval 

configured for the location) . The total size of the 
framed packet will be 7 bytes. 
Field Size: Description: 

1 byte Packet Type = 0x80 

10 1 byte Packet Subtype = OxOF 

2 bytes Packet Size = 7 

1 byte Flags 

Defined bits include: 

0x01 Scan file system and update 
15 W_CONTENTj3ACHE table 

0x02 Synchronize the database with 

the server 
0x04 Synchronize subscriber 
records in cache 
20 OxFF Do full synchronization 

2 bytes CRC 

Synchronize Response 

Sent by the communications process on the master 
25 terminal in response to a Synchronize packet, 
indicating that the process will begin the 
synchronization as soon as possible. The total size of 
the framed packet will be 6 bytes. 

Field Size: Description: 

30 1 byte Packet Type = 0x80 

1 byte Packet Subtype = 0x10 

2 bytes Packet Size = 6 
2 bytes CRC 

35 Receipt Validation 

Receipt validation packets are traditionally 
sent by validation terminals, but can be sent by any 
authorized ADMIN terminal. Receipt IDs are printed on 
all receipts or coupons generated at ADMIN terminals. 



SUBSTITUTE SHEET (RULE 26) 



3NSDOCID: <WO 0038089A2_I_> 



WO 00/38089 ^ w PCT/CA99/01201 



39 

The receipt ID is printed in two formats - a bar-code 
symbol. using the Code 39 symbology, and a 15-digit 
numerical string, printed in 5 groups of 3 digits. 

This packet is also used to redeem receipts and 
5 loyalty points the subscriber has on account. This is 
typically done by game terminals, following a 
Subscriber Account Information query to gather the 
current account inf ormation. 

Receipt validation packets have the following 
10 data structure: 

Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x02 

15 2 bytes Packet Size = 30 

[BEGIN ENCRYPTED AREA] 

6 bytes Validating Terminal ID 

1 byte Receipt ID length (10 or 15) 
N bytes Receipt ID 

20 (Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 

The length of the receipt data governs its 
format. The formats supported, and their lengths, are 
25 shown here: 

Length : Format : 

10 10 Code-39 Bar-code symbols, as read from the 

printed receipt 
14 4-byte value representing the loyalty program 

30 ID 

4-byte value representing the number of points 

being redeemed 

4-byte value representing the subscriber ID 
2-byte value representing the PIN 
35 15 15 decimal digits, as printed on the receipt 

16 10 Code-39 Bar-code symbols, as read from the 

printed coupon 

4-byte value representing the subscriber ID 
2-byte value representing the PIN 
40 21 15 digit receipt ID of coupon being redeemed 

4-byte value representing the subscriber ID 
2-byte value representing the PIN 



SUBSTITUTE SHEET (RULE 26) 



© o 



WO 00/38089 ^ PCT/CA99/01201 



40 

The receipt ID should appear in the packet in the 
same order as entered or scanned from the receipt. For 
numeric IDs, send the ASCII code for each digit. For 
bar-code format, send the ASCII codes for the bar-code 
5 symbols as defined in the Code 39 bar-code symbology. 
Receipt Validation Response 

When the server receives a Receipt Validation 
query, it will attempt to validate the receipt ID in 
the packet, and will return this response packet with 
10 the results. 

Receipt validation response packets have the 
following data structure: 

Field Size: Description: 

1 byte Packet Type = 0x81 

15 1 byte Packet Subtype = 0x03 

2 bytes Packet Size = 14 or 22 
[BEGIN ENCRYPTED AREA] 

1 byte Status indicator 

0 = Coupon valid-payment authorized 
20 1 = Coupon not found on server 

2 = System error 

3 = Coupon already redeemed 

4 = Insufficient loyalty points 

5 = Invalid loyalty program 
25 6 = Subscriber not found 

7 = Invalid PIN 

8 = Subscriber account frozen 
15 bytes Authorization code (only present if 

status=0) 

30 (Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 

The authorization code will be an ASCII string 
consisting of digits only. It will always contain 15 
35 digits. 

Subscriber Information 

Subscriber information queries are sent by 
clients when a subscriber logs on to a terminal and 
that subscriber' s information is not in the local 
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database cache. This query will cause table and file 
downloads between the query and the response. 

Subscriber information request packets have the 
following data structure: 

5 Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x04 

2 bytes Packet Size = 38 
[BEGIN ENCRYPTED AREA] 

10 6 bytes Terminal ID requesting the information 

1 byte Card type used in the request 

1 = NAN I card 

2 = Credit card 

3 = Debit card 
25 4 = Name 

5 = Name and SSN 
16 bytes Card data 

2 bytes PIN 

(Pad encrypted area to even 8-byte boundary with zeros) 
20 [END ENCRYPTED AREA] 
2 bytes CRC 

If the card type is 1 (ADMIN Cards) , the card 

data should be filled with the 10-digit ID read from 

the NANI card followed by 6 spaces. 

25 If the card type is 2 or 3 (Credit or Debit 

card) , the card data field should be the data read from 

the PAN field on the card stripe (either track or track 

2) . 

If the card type is 4 (Name) , the card data field 
30 should be filled with 14 characters of the player's 
name followed by 2 spaces. 

If the card type is 5 (Name and SSN) , the card 
data field should be filled with 10 characters of the 
player' s name followed by a 4-byte representation of 
35 the players SSN (treated as an integer, stored LSB 

first)/ followed by 2 spaces. This is the only case in 
which non-ASCII data is stored in the card data field. 
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Subscriber Information Response 

When the server received a request for subscriber 
information, it will collect the information about the 
subscriber (if found) into table and file download 

5 packets, and transmit them to the client. When all 
downloads are complete, this response packet will be 
sent to the client. If there is an error or if the 
subscriber is not found in the server's database, this 
response will be transmitted right away. 

10 Subscriber information response packets have the 

following data structure: 

Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x05 

15 2 bytes Packet Size = 14 or 22 

[BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID requesting the information 

1 byte Status Indicator 

0 = Information found - subscriber 
20 valid 

1 = Information not found 

2 = System error 

3 = Invalid PIN 

4 bytes Subscriber ID (only present if status 

25 = 0) 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 

If status is 0 or 3, this packet will be preceded 
30 by a one or more table and/or file download packets 
containing the subscriber information. When the 
response packet is received, all subscriber data will 
have been downloaded to the terminal . Responses with 
status codes 1 or 2 will be returned right away. 
35 Account Withdrawal 

This query is sent by clients when a subscriber 
requests a withdrawal of money currently on account. 

Account withdrawal packets have the following 
data structure : 
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Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype - 0x06 

2 bytes Packet Size = 22 
5 [BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID requesting the transaction 

4 bytes Subscriber ID 

2 bytes PIN number entered by subscriber 

4 bytes Amount to be withdrawn (in US cents) 

10 (Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 
2 bytes CRC 

The server will enforce limits on the maximum and 
minimum amounts for which a withdrawal can be made. 
IS Account Withdrawal Response 

When an account withdrawal request is made, the 
server will attempt to perform the withdrawal, then 
will send this response packet to the client with the 
results • 

20 Account withdrawal response packets have the 

following data structure: 

Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x07 

25 2 bytes Packet Size = 22 or 38 

[BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID performing the withdrawal 

4 bytes Subscriber ID 

1 byte Status indicator 

30 0 ~ Withdrawal authorized 

1 = Insufficient funds 

2 = Subscriber not found on server 

3 = Invalid PIN 

4 = Account frozen 
35 5 = System error 

6 = Invalid amount 
15 bytes Authorization ID for withdrawal (only 

present if status = 0) 
4 bytes New account balance, in US cents (only 

40 present if status = 0) 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 
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Account Deposit 

This query is sent by the clients when a 
subscriber requests a deposit of money to his or her 
own ADMIN account. 
5 Account deposit packets have the following data 

structure : 

Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x08 
10 2 bytes Packet Size = 22 

[BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID requesting the transaction 

4 bytes Subscriber ID 

2 bytes PIN number entered by subscriber 

15 4 bytes Amount to be deposited (in US cents) 

[END ENCRYPTED AREA] 
2 bytes CRC 

Account Deposit Response 

When an account deposit request is made, the 
20 server will attempt to perform the deposit, then will 
send this response packet to the client with the 
results • 

Account deposit response packets have the 
following data structure: 

25 Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x09 

2 bytes Packet Size = 22 or 38 
[BEGIN ENCRYPTED AREA] 

30 6 bytes Terminal ID performing the withdrawal 

4 bytes Subscriber ID 

1 byte Status indicator 

0 = Deposit accepted 

1 = Account limit exceeded 

35 2 = Subscriber not found on server 

3 = Invalid PIN 

4 = Account frozen 

5 = System error 

6 = Invalid amount 

40 15 bytes Authorization ID for deposit (only 

present if status = 0) 
4 bytes New account balance, in US cents (only 

present if status = 0) 
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(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 
2 bytes CRC 

Subscriber Account Data Request 

5 This query is sent by clients when a subscriber 

requests a full report on his or her current account 
status . 

Subscriber account data request packets have the 
following data structure: 

20 Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = OxOA 

2 bytes Packet Size = 22 
[BEGIN ENCRYPTED AREA] 

15 6 bytes Terminal ID 

4 bytes Subscriber ID 

2 bytes PIN 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 
20 2 bytes CRC 

Subscriber Account Data Response 

When the server received an account data request, 
it collects the information about the subscriber's 
account and sends this response packet. 
25 Subscriber account data response packets have the 

following data structure: 

Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = OxOB 

30 2 bytes Packet Size = 22 or 38+ 

[BEGIN ENCRYPTED AREA] 
6 bytes Terminal ID 

4 bytes Subscriber ID 

1 byte Status Indicator 
35 0 = Success 

1 = Account Frozen 

2 = Subscriber not found 

3 = Invalid PIN 

4 = System error 

40 4 bytes Account balance (in US cents) (on success) 

4 bytes Amount withdrawn pending confirmation (in US 

cents) (on success) 

2 bytes Number of outstanding orders (on success) 

6 bytes Order ID (on success) 

45 40 bytes Item name (on success) 
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4 bytes Date and time order received (on success) 
4 bytes Date and time order sent to supplier (on 

success) 

4 bytes Expected ship date and time (on success) 
5 4 bytes Date and time order shipped (on success) 

4 bytes Date and time order canceled (on success) 
2 bytes Number of coupons (on success) 

4 bytes Coupon ID (on success) 
40 bytes Description (on success) 
20 6 bytes Receipt ID (on success) 

4 bytes Face value (on success) 

4 bytes Expiration date (on success) 
2 bytes Number of loyalty programs (on success) 

4 bytes Loyalty program ID (on success) 
75 40 bytes Loyalty program name (on success) 

20 bytes Loyalty point label (on success) 
4 bytes Number of points (on success) 
(Pad encrypted are to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 
20 2 bytes CRC 

Winning Redemption Play 

When a redemption game has been played that awards 
a prize, and the prize has a limited number of units 
available (a non-zero value for the NUMJREMAINING field 

25 in the database) , or that wins a prize that includes a 
pool amount, the terminal should immediately issue this 
query to update its local prize information. 

This packet permits prize pools to be maintained 
across several locations, without the chance that more 

30 prizes that are available will be given out. It also 
allows the server to update the local pool value so 
players can see pool contributions from multiple 
locations . 

Winning redemption play packets have the following 
35 data structure: 

Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = OxOC 

2 bytes Packet Size = 38 + 
40 [BEGIN ENCRYPTED AREA] 

4 bytes Subscriber ID playing the redemption game (LSB 

first) 

6 bytes Terminal ID on which the redemption game was 

played 
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4 bytes Service ID on which redemption game was played 

(LSB first) 

1 byte Player Station (8 bit flags, position 0 = station 

1, etc.) 

5 1 byte Active Stations (8 bit flags, position 0 = 

station 1, etc.) 
4 bytes Start Date and Time (UTC format, LSB first) 

4 bytes End Date and Time (UTC format, LSB first) 

1 byte Flags 
10 0x01 Equipment failed during game 

0x02 Score is invalid 
1 byte Number of statistics (n) 

[BEGIN REPEATING LIST] 

4 bytes Statistic ID (LSB first) 
15 4 bytes Statistic Value (LSB first) 

[END REPEATING LIST] 

1 byte Number of redemption games entered with the play 

(m) 

[BEGIN REPEATING LIST] 
20 4 bytes Redemption ID (LSB first) 

2 bytes Par level beaten (LSB first) 
4 bytes Par score beaten (LSB first) 
4 bytes Derived score achieved by subscriber (LSB 
first) 

25 4 bytes Prize ID awarded (LSB first) 

[END REPEATING LIST] 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 

30 The subscriber ID may be 0 if the redemption game 

is unidentified. 

Winning Redemption Play Response 

When a winning redemption play query is received at 
the server, it will adjust the number of the awarded 

35 prizes remaining (if that number is limited) , and/or it 
will calculate the pool amount to award to the player 
based on the current value of the collective prize 
pool. (If the par level has an associated pool amount). 
It will send this response packet back to the terminal, 

40 indicating the amount of the pool the player should be 
awarded and updating the pool value and number of 
prizes remaining as appropriate. 

Winning redemption play response packets have the 
following data structure: 

45 



SUBSTITUTE SHEET (RULE 26) 



WO 00/38089 ^ W PCT/CA99/01201 



48 

Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = OxOD 

2 bytes Packet Size = 14+ 
5 [BEGIN ENCRYPTED AREA] 

4 bytes Current pool value (LSB first) 

1 byte Number of par levels being updated (n) 

[BEGIN REPEATING LIST] 

4 bytes Redemption ID being updated (LSB 

20 first) 

2 bytes Par level being updated {LSB first) 

4 bytes New pool value (after award) (LSB 

first) 

4 bytes Pool amount to award (LSB first) 

75 4 bytes Number of prizes remaining (LSB 

first) 

[END REPEATING LIST] 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 
20 2 bytes CRC 

Subscriber ID Request 

A subscriber ID request is used when a terminal 
needs to register a new player who does not have a NANI 
card. It generates a unique, unassigned subscriber ID 
25 that the player's card data can be associated with. 

Subscriber ID request packets have no data. The 
packet header is sufficient to convey the request. 

Field Size: Description: 

1 byte Packet Type = 0x81 

30 1 byte Packet Subtype = OxOE 

2 bytes Packet Size = 6 
2 bytes CRC 

Subscriber ID Response 

Upon completion, this request will have registered 
35 this ID as "allocated but unassigned". When the player 
registers, the terminal should send in a New Subscriber 
Event to assign the ID to the player. 

Subscriber ID response packets have the following 
data structure: 

40 Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = OxOF 
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2 bytes Packet Size = 14 

[BEGIN ENCRYPTED AREA] 

1 byte Status Code 

0 = Success 

5 1 = Failure 

4 bytes Subscriber ID (only present on success) 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 

10 Credit /Debit Request 

This request is issued by a terminal when a player 
presents a credit or debit card and requests that money 
be transferred on to the terminal for play, or into the 
player's account. 
15 Credit/debit request packets have the following 

data structure: 

Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x10 
20 2 bytes Packet Size = 46 

[BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID requesting the transaction 

4 bytes Subscriber ID 

2 bytes PIN (LSB first) 

25 1 byte Card format (FC from track 1 stripe) 

16 bytes Card data (PAN code from track 1 stripe) 

4 bytes Expiration date (4 bytes of addition 

data from track 1 stripe) 
2 bytes Debit PIN (LSB first, zero for credit 

30 cards) 

4 bytes Amount to be withdrawn (in US cents, LSB 

first) 

1 byte Disposition 

0 = Place in subscriber account 
35 1 = Credit local terminal 

(pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 

The card format, card data and expiration date 
40 fields should all appear exactly as read from the 

magnetic stripe on the card. The PIN should be entered 
by the player for debit cards only. 
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Save State Request 

This request is used when a player wants to save 
the state of a game or other service (including the 
user interface shell) for later restoration (on this or 
5 another terminal) . 

Save State request packets have the following data 
structure : 

Field Size: Description: 

1 byte Packet Type = 0x81 

10 1 byte Packet Subtype = 0x12 

2 bytes Packet Size = 46 
[BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID on which the state is being 

saved 

15 4 bytes Subscriber ID 

2 bytes PIN 
4 bytes Service ID 

1 byte Slot Number 

2 0 bytes Save State Name 

20 (Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 
2 bytes CRC 

This packet is sent to the server to obtain a File 
ID. That file ID can then be used to upload the save 
25 state file to the server. 
Restore State Request 

This request is issued when a player wants to 
restore a state that was saved previously on this or 
another terminal. The server will return the File ID 
30 of the save state file, and if the download flag 

indicates a download is required, it will download the 
save state file between the request and the response. 

Restore State request packets have the following 
data structure: 

35 Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x14 

2 bytes Packet Size = 30 
[BEGIN ENCRYPTED AREA] = 17 
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6 bytes Terminal ID on which the state is being 

restored 

4 bytes Subscriber ID 
2 bytes PIN 

5 4 bytes Service ID 

1 byte Slot number 

1 byte Download flag 

0 = Do not download the save state 
file 

10 1 = Download the file if it exists 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 

Even if the file exists on the local machine, this 
15 request should be made before the player is allowed to 
load it, to assure the player is authenticated as the 
owner of the data, and also to verify the File ID of 
the save state file as stored in the 

5 UB S CR I BE R_S AVE_S TATE table. 
20 Restore State Response 

When the server received a restore state request, 
it will search for the saved state data, validate the 
integrity of the file, and return the file ID to the 
client. If the client requested a download of the 
25 file, the file will be transmitted before the response 
is returned* 

Restore State response packets have the following 
data structure: 

Field Size: Description: 

30 1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x15 

2 bytes Packet Size = 14 
[BEGIN ENCRYPTED AREA] 

1 byte Status Indicator 

35 0 = Permission to use save state granted 

1 = Requested save state not found on 

server 

2 = Subscriber not found on server 

3 = Invalid PIN 

40 4 = Service not found on server 

5 = Account frozen 

6 = System error 
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4 bytes File ID (only present if status = 0) 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 
2 bytes CRC 

5 New Subscriber Card Request 

This request is used to associate a new card number 
with an existing subscriber. This allows players to 
use multiple cards (including their name or name/SSN 
combination) to identify themselves to the network* 
20 This request will succeed only if the new card ID 

is unique throughout the entire ADMIN network. 

New Subscriber Card request packets have the 
following data structure: 

Field Size: Description: 

IS 1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x16 

2 bytes Packet Size = 38 
[BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID 

20 4 bytes Subscriber ID 

2 bytes PIN 

1 byte Card Type 

1 = ADMIN card 

2 = Credit card 
25 3 = Debit card 

4 = Name 

5 = Name and SSN 
16 bytes Card Data 

(Pad encrypted area to even 8-byte boundary with zeros) 
30 [END ENCRYPTED AREA] 

2 bytes CRC 

New Subscriber Card Response 

When a new subscriber card request is received by 
the server, it will validate the uniqueness of the card 
35 data and create a new card record for the subscriber, 
returning the result in this packet. 

New Subscriber Card response packets have the 
following data structure: 

Field Size: Description: 

40 1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x17 
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2 bytes Packet Size = 22 

[BEGIN ENCRYPTED AREA] 
6 bytes Terminal ID 

4 bytes Subscriber ID 

5 1 byte Status indicator 

0 = Card added successfully 

1 = Card is registered to another 

subscriber 

2 = Subscriber not found on server 
10 3 = Invalid PIN 

4 = Card already registered to this 

subscriber 

5 = Account frozen 

6 = System error 

15 (Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 
2 bytes CRC 

Reserve Merchandise 

Reserve merchandise request packets are used to 
20 reserve an item of merchandise. The requester can 

specify attribute values for the item, which the server 
will try to match. 

Reserve merchandise request packets have the 
following data structure: 

25 Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x18 

2 bytes Packet Size = 38 + 
[BEGIN ENCRYPTED AREA] 

30 6 bytes Terminal ID 

4 bytes Subscriber ID 

2 bytes PIN 

4 bytes Item ID to reserve 

4 bytes Quantity to reserve 

35 4 bytes Price offered 

1 byte Number of attributes 

1 byte Attribute ID 

2 bytes Attribute data size 
Variable Attribute data 

40 (Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 



SUBSTITUTE SHEET (RULE 26) 

INSOOCID: <WO 0038089A2J_> 



© 



WO 00/38089 w 1 PCT/CA99/01201 



54 

Reserve Merchandise Response 

Reserve Merchandise response packets indicate to 
the requester whether the reservation was successful, 
and if so, what the actual attribute values of the 
5 reserved item is. If the requested quantity could not 
be met, the largest quantity that could be reserved is 
returned. 

Reserve Merchandise response packets have the 
following data structure: 

10 Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = 0x19 

2 bytes Packet Size = 38+ 
[BEGIN ENCRYPTED AREA] 

15 6 bytes Terminal ID 

4 bytes Subscriber ID 

4 bytes Item ID being reserved 

1 byte Status code 

0 Reservation successful 

20 1 No items remain in inventory 

2 Invalid request 

3 System error 

4 bytes Quantity reserved (on success) 

4 bytes Price of reserved items (on success) 

25 6 bytes Reservation ID (on success) 

1 byte Number of attributes 

1 byte Attribute ID 

2 bytes Attribute data size 
Variable Attribute data 

30 (Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes N CRC 

Purchase Merchandise 

Purchase merchandise request packets are used to 
35 purchase merchandise that was previously reserved with 
a Reserve merchandise query. The requester can specify 
attribute values for the item, which the server will 
try to match. 

Purchase merchandise request packets have the 
40 following data structure: 
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Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = OxlA 

2 bytes Packet Size = 30+ 
5 [BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID 

4 bytes Subscriber ID 

2 bytes PIN 

6 bytes Reservation ID (on success) 

10 4 bytes Purchase price 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 
2 bytes CRC 

Purchase Merchandise Response 

15 Purchase Merchandise response packets verify to the 

requester that the purchase has been processed by the 
server and that the money should be deducted from the 
player's funds (either account fees or cash). 

Purchase merchandise response packets have the 

20 following data structure: 

Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = OxlB 

2 bytes Packet Size = 22 or 30 
25 [BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID 

4 bytes Subscriber ID 

1 byte Status code 

0 Purchase successful 

30 1 No items remain in inventory 

2 Invalid request 

3 System error 
6 bytes Order ID (on success) 

(Pad encrypted area to even 8-byte boundary with zeros) 
35 [END ENCRYPTED AREA] 

2 bytes CRC 

Release Merchandise 

Release merchandise request packets are used to 
release merchandise that was previously reserved with a 
40 Reserve merchandise query. The requester can specify 
attribute values for the item, which the server will 
try to match. 
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Purchase merchandise request packets have the 
following data structure: 

Field Size: Description: 

1 byte Packet Type = 0x81 

5 1 byte Packet Subtype = OxlC 

2 bytes Packet Size = 30 
[BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID 

4 bytes Subscriber ID 

10 2 bytes PIN 

6 bytes Reservation ID (on success) 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 
2 bytes CRC 

IS Release Merchandise Response 

Release merchandise response packets verify to the 
requester that reserved merchandise has been released. 

Purchase merchandise response packets have the 
following data structure: 

20 Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = OxlD 

2 bytes Packet Size = 30 
[BEGIN ENCRYPTED AREA] 

25 6 bytes Terminal ID 

4 bytes Subscriber ID 

6 bytes Reservation ID 

1 byte Status code 

0 Release successful 

30 1 Invalid request 

2 System error 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 

35 Subscriber Ranking Request 

A request for a subscriber's current ranking in one 
or more tournament brackets. This can be used to 
request ranking in brackets that have ended and are 
beyond their posting period. 
40 Subscriber ranking request packets have the 

following data structure: 
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Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = OxlD 

2 bytes Packet Size = 30+ 
5 [BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID 

4 bytes Subscriber ID 

2 bytes PIN 

1 byte Number of tournament brackets 
10 4 bytes Tournament ID 

1 byte Bracket ID 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 

IS Subscriber Ranking Response 

The response to the subscriber ranking request 
packet. This packet contains the subscriber's current 
position and ranking score in each of the requested 
tournament brackets that the subscriber has 
20 participated in. If the subscriber has not yet played 
in one of the requested brackets, or the bracket is not 
found on the server, it will not be included in the 
list. 

Subscriber ranking response packets have the 
25 following data structure: 

Field Size: Description: 

1 byte Packet Type = 0x81 

1 byte Packet Subtype = OxlE 

2 bytes Packet Size = 22 
30 [BEGIN ENCRYPTED AREA] 

1 byte Status 

0 = Query succeeded 

1 = Account frozen 

2 = Subscriber not found 
3S 3 = Invalid PIN 

4 = System error 
4 bytes Subscriber ID 

1 byte Number of tournament brackets 

4 bytes Tournament ID 

40 1 byte Bracket ID 

2 bytes Rank 
4 bytes Score 

4 bytes Score Date and Time 

(Pad encrypted area to even 8-byte boundary with zeros) 
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[END ENCRYPTED AREA] 
2 bytes CRC 

Event: Packets 

Event packets are transmitted on sockets connected 
5 to the Event services IP port, or over an asynchronous 
POS network connection. In either case, they use a 
transmit-ack lockstep exchange. The client transmits 
an event packet, the server responds with an Ack. If 
the server does not respond within 1 second, the client 
10 resends the event packet up to 5 times, then fails and 
moves on to its next event. If the server sends a Nak, 
the packet should be resent right away. These timeouts 
may need to be tuned for Internet-based transmission. 
The entire data portion of the event packet is 
15 encrypted using the encryption parameters negotiated 
for the connection. 
Alarm 

Alarm event packets have the following data 
structure : 

20 Field Size: Description: 

1 byte Packet Type = 0x82 

1 byte Packet Subtype = 0x00 

2 bytes Packet Size 
[BEGIN ENCRYPTED AREA] 

25 6 bytes Terminal ID of the machine reporting the 

alarm 

2 bytes Alarm code being reported (LSB first) . 

Currently defined values are shown below. 
4 bytes Time the alarm was reported (UTC format, 

30 LSB first) 

1 byte Flag indicating whether the alarm was 

handled by the terminal 

(1 if the terminal handled the alarm 
with a local handler) 
35 2 bytes Alarm data size (LSB first) 

Variable Alarm data. The content of this field 

depends on the alarm type. The formats for 
each defined alarm code are shown below. 
(Pad data portion of packet to even 8-byte boundary 
40 with zeros) 

[END ENCRYPTED AREA] 
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10 



15 



20 



25 



30 



35 



40 



2 bytes 

Alarm 
Code: 

1 
2 



CRC 



5 
6 
7 
8 

12 
13 
18 
19 
22 

23 



24 

25 

26 
27 
29 



Meaning: 

Hard reset (power up) 
Soft reset 
Hardware failure 

Firmware failure 

Bill acceptor full 
Coin jam 
Bill jam 
Network disabled 
Game time-out 
Hard drive full 
Printer error 
Printer paper low 
Cable disconnected 

Security alarm 



Enabled by technician 

Disabled by technician 

Immediate call requested 
Queue entry aged 
Serial number changed 



Data: 

None 
None 

ASCII diagnostic 

message (optional) 

ASCII diagnostic 

message (optional ) 

None 

None 

None 

None 

None 

None 

None 

None 

ASCII diagnostic 
message (optional) 
Binary position of 
switch positions (use 
32 bits) 

Technician ID enabling 

terminal 

Technician ID 

disabling terminal 

None 

None 

None 



Alarm events are queued to the server as soon as 
they are detected. Alarms of the following types are 
considered critical and should be transmitted right 



away: 



Hardware failure 
Bill acceptor full 
Bill jam 

Cable disconnected 
Immediate call request 



Firmware failure 
Coin jam 
Printer error 
Security alarm 



Tournament Play 

Tournament play event packets have the following 
data structure: 



45 



Field Size: 
1 byte 

1 byte 

2 bytes 



Description : 

Packet Type = 0x82 
Packet Subtype = 0x01 
Packet Size 
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[BEGIN ENCRYPTED AREA] 

4 bytes Subscriber ID playing the tournament game 

(LSB first) 

6 bytes Terminal ID on which the tournament game 

5 was played 

4 bytes Service ID on which tournament game was 

played (LSB first) 
1 byte Player Station (8 bit flags, position 0 = 

station 1, etc.) 
10 1 byte Active Station (8 bit flags, position 0 = 

station 1, etc. ) 
4 bytes Start Date and Time (UTC format, LSB first) 

4 bytes End Date and Time (UTC format, LSB first) 

1 byte Flags 
25 0x01 Equipment failed during 

game 

0x02 Score is invalid 

0x04 Player should be 

disqualified 
20 1 byte Number of statistics (n) 

4 bytes Statistic ID (LSB first) 

4 bytes Statistic Value (LSB first) 

1 byte Number of tournament games entered with the 
25 play (m) 

4 bytes Tournament ID entered (LSB first) 
1 byte Bracket ID entered 

4 bytes Derived score achieved by subscriber 
(LSB first) 

30 

(Pad data portion of packet to even 8-byte boundary 
with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 

35 Redemption Play 

Redemption play event packets have the following 
data structure: 

Field Size: Description: 

1 byte Packet Type = 0x82 

40 1 byte Packet Subtype = 0x02 

2 bytes Packet Size 
[BEGIN ENCRYPTED AREA] 

4 bytes Subscriber ID playing redemption game (LSB 

first) 

45 6 bytes Terminal ID on which redemption game was 

played 

4 bytes Service ID on which redemption game was 

played (LSB first) 
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1 byte Player Station (8 bit flags, position 0 = 

station 1, etc.) 
1 byte Active Stations (8 bit flags, position 0 = 

station 1 , etc. ) 
5 4 bytes Start Date and Time (UTC format, LSB first) 

4 bytes End Date and Time (UTC format, LSB first) 

1 byte Flags 

0x01 Equipment failed during 

game 

10 0x02 Score is invalid 

1 byte Number of statistics (n) 

4 bytes Statistic ID (LSB first) 

4 bytes Statistic Value (LSB first) 

15 1 byte Number of redemption games entered with the 

play (m) 

4 bytes Redemption ID (LSB first) 
2 bytes Par level beaten (LSB first) 
4 bytes Par score beaten (LSB first) 
20 4 bytes Derived score achieved by subscriber 

(LSB first) 

4 bytes Pool amount awarded (LSB first) 

(Pad data portion of packet to even 8-byte boundary 
25 with zeros) 

[END ENCRYPTED AREA] 

2 bytes CRC 

Meter Readings 

Meter readings event packets have the following 
30 data structure: 

Field Size: Description: 

1 byte Packet Type = 0x82 

1 byte Packet Subtype = 0x03 

2 bytes Packet Size 
35 [BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID on which the meters were 

collected 

4 bytes The date and time meters were collected (in 

UTC format, LSB first)- 
40 2 bytes Number of terminal meters included (LSB 

first) (n) 

4 bytes Terminal Meter ID (LSB first) 
4 bytes Terminal Meter Value (LSB first) 

45 2 bytes Number of service meters (LSB first) (m) 

4 bytes Service ID of the meter (LSB first) 
4 bytes Meter ID of the meter (LSB first) 
4 bytes Meter Value of the meter (LSB first) 



SUBSTITUTE SHEET (RULE 26) 



WO 00/38089 ^ w PCT/CA99/0120I 

J 

62 

• * • 

(Pad data portion of packet to even 8-byte boundary 
with zeros) 
[END ENCRYPTED AREA] 
5 2 bytes CRC 

Terminal manufacturers should support as many of 

the following pre-defined terminal meter IDs as 

possible, as well as any additional meters available: 

Meter ID: Meaning: 

20 1 Left slot coins in 

2 Right slot coins in 

3 3 rd slot coins in 

4 4 th slot coins in 

5 Paid credits 

j5 6 Total collection (in cents) 

7 Service credits 

8 Total plays 

9 Total uptime (minutes) 
10 Number of hard resets 

20 11 Number of soft resets 

Terminal meters should never reset to zero. They 
should accumulate in 32-bit fields over the lifetime of 
the terminal. Relative values will be computed between 
two consecutive readings at the database. 
25 Ad Statistics 

Ad statistics event packets have the following data 
structure: 

Field Size: Description: 

1 byte Packet Type = 0x82 

30 1 byte Packet Subtype = 0x04 

2 bytes Packet Size 
[BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID on which the statistics were 

collected 

35 4 bytes The date and time statistics were collected 

(in UTC format, LSB first) 
2 bytes Number of unidentified ads (n) 

4 bytes Target ID (LSB first) 
4 bytes Number of plays 



40 



2 bytes Number of identified ad exposures (LSB 

first) (m) 
4 bytes Target ID (LSB first) 
4 bytes Subscriber ID (LSB first) 
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4 bytes Date and time the ad was played (UTC 
format/ LSB first) 

• • * 

(Pad data portion of packet to even 8-byte boundary 
5 with zeros) 

[END ENCRYPTED AREA] 
2 bytes CRC 

Ad statistics are accumulated on each terminal and 

queued at midnight each night (or whenever the terminal 

10 detects the current day has changed, in case it is 

powered off at midnight) . The packet reports all ad 
plays for the day. As soon as this packet is queued, 
the ad play records can be deleted from the terminal, 
and a new day's record keeping begun* The queued entry 

IS must not be deleted until successfully received at the 
server and acknowledged. 
Service Accesses 

Service accesses event packets have the following 
data structure: 

20 Field Size: Description: 

1 byte Packet Type = 0x82 

1 byte Packet Subtype = 0x05 

2 bytes Packet Size 
[BEGIN ENCRYPTED AREA] 

25 6 bytes Terminal ID on which the statistics were 

collected 

4 bytes The date and time statistics were collected 

(in UTC format, LSB first) 
2 bytes Number of service accesses being reported 

30 (LSB first) (n) 

4 bytes Service ID being accessed (LSB first) 
1 byte Profile used 

4 bytes Start date and time of access (UTC 

format, LSB first) 
35 4 bytes End date and time of access (UTC format, 

LSB first) 
4 bytes Subscriber ID (LSB first) 
4 bytes Cash funds used (LSB first) 
4 bytes Account funds used (LSB first) 



40 



(Pad data portion of packet to even 8-byte boundary 
with zeros) 
[END ENCRYPTED AREA] 
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2 bytes CRC 

This packet tracks all accesses to any service on 
the terminal. Each time a player plays a game or 
engages in a session in any other service, the data 
5 should be stored. This packet should be generated each 
evening at midnight for the day's service accesses (or 
whenever the terminal detects the current day has 
changed) . 
Down Time 

20 Down time event packets have the following data 

structure : 

Field Size: Description: 

1 byte Packet Type = 0x82 

1 byte Packet Subtype = 0x06 
15 2 bytes Packet Size 

[BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID on which the down times are 

being reported 
4 bytes The date and time down times were reported 

20 (in UTC format, LSB first) 

2 bytes Number of down times being reported (LSB 

first) (n) 

4 bytes Technician ID responsible for the down 
time (LSB first) 
25 4 bytes Start date and time of down time (UTC 

format, LSB first) 
4 bytes End date and time of down time (UTC 
format, LSB first) 

... 

30 (Pad data portion of packet to even 8-byte boundary 
with zeros) 
[END ENCRYPTED AREA] 
2 bytes CRC 

This packet tracks all down times experienced by a 
35 terminal. Games should periodically update some non- 
volatile timestamp while they are running, and then 
test this value on powerup to see how long the power 
outage was, and report this as down time. When a 
technician administratively takes the game down through 
40 a service menu, this is also logged in this packet. 
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This packet should be generated each evening at 
midnight for the day' s down times (or whenever the 
terminal detects the current day has changed) . 
Hew Subscriber 
5 New subscriber event packets have the following 

data structure : 

Field Size: Description: 

1 byte Packet Type = 0x82 

1 byte Packet Subtype = 0x07 
10 2 bytes Packet Size 

[BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID on which the subscriber 

registered 

4 bytes Subscriber ID being registered (LSB first) 

15 26 bytes Alias entered by the subscriber 

26 bytes Street address entered by the subscriber 

10 bytes Postal code entered by the subscriber 

10 bytes Phone number entered by the subscriber 

20 bytes First name entered by subscriber 

20 2 0 bytes Last name entered by subscriber 

2 bytes Middle initial entered by subscriber 
1 byte Birth day entered by subscriber 

1 byte Birth month entered by subscriber 

2 bytes Birth year entered by subscriber (LSB 
25 first) 

1 byte Gender entered by subscriber (0 = male, 

1 = female) 
9 bytes SSN entered by subscriber 

2 bytes PIN entered by the subscriber 
30 1 byte Number of cards to register 

1 byte Card Type 

1 = ADMIN card 

2 = Credit card 

3 = Debit card 
35 4 = Name 

5 = Name and SSN 
16 bytes Card Data 

(Pad data portion of packet to even 8-byte boundary 
40 with zeros) 

[END ENCRYPTED AREA] 
2 bytes CRC 

New subscriber events are queued when players 

register a new card. They are queued at the time the 

45 data is entered, but do not need to be sent right away. 
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However, if the player subsequently plays any games 
that generate queue entries, the terminal must ensure 
that this event is transmitted to the server before any 
game plays for that player* This is to ensure that the 

5 server has established an account for the player before 
attaching a game play to it. 

Any of the registered cards that are included in 
the packet that already exist on the server or fail for 
some other reason will be skipped, but the subscriber 

10 will be created regardless. A card of type "NANI Card" 
with a card ID equal to the value of the subscriber ID 
will be created automatically. 
New Team 

New team event packets have the following data 
IS structure : 

Field Size: Description: 

1 byte Packet Type = 0x82 

1 byte Packet Subtype = 0x08 

2 bytes Packet Size 
20 [BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID on which the subscriber 

registered 

4 bytes Subscriber ID of team being registered (LSB 

first) 

25 26 bytes Alias entered by the team 
2 bytes PIN entered for team 

1 byte Number of members 

4 bytes Subscriber ID 
1 byte Flags 

(Pad data portion of packet to even 8-byte boundary 
with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 

New team events are queued when teams register. 
They are queued at the time the data is entered, but do 
not need to be sent right away. However, if the team 
subsequently plays any games that generate queue 



30 



35 
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entries, the terminal must ensure that this event is 
transmitted to the server before any game plays for 
that team. This is to ensure that the server has 
established an account for the team before attaching a 
5 game play to it* 
Issued Coupons 

Issued coupons event packets have the following data 
structure: 

Field Size: Description: 

10 1 byte Packet Type = 0x82 

1 byte Packet Subtype = 0x09 

2 bytes Packet Size 
[BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID on which the down times are 

15 being reported 

2 bytes Number of coupons being reported (LSB 

first) (n) 

4 bytes Coupon ID issued (LSB first) 
4 bytes Subscriber ID coupon was issued to (LSB 
20 first) 

4 bytes Date and time coupon was issued (UTC 

format, LSB first) 
6 bytes Receipt ID 
1 byte Flags 

25 

(Pad data portion of packet to even 8-byte boundary 
with zeros) 

[END ENCRYPTED AREA] 
2 bytes CRC 

30 This packet tracks all coupons issued by a 

terminal • This packet should be generated each night 
at midnight for the day's coupons (or whenever the 
terminal detects the current day has changed) . 
Loyalty Point Awards 

35 Loyalty point award event packets have the 

following data structure: 

Field Size: Description: 

1 byte Packet Type = 0x82 

1 byte Packet Subtype = OxOA 

40 2 bytes Packet Size 

[BEGIN ENCRYPTED AREA] 
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6 bytes Terminal ID on which the awards are being 

reported 

2 bytes Number of awards being reported (LSB first) 

(n) 

5 4 bytes Subscriber ID receiving the award (LSB 

first) 

4 bytes Loyalty Program ID (LSB first) 
2 bytes Number of points awarded (LSB first) 
4 bytes Date and time the award was made (UTC 
10 format, LSB first) 

(Pad data portion of packet to even 8-byte boundary 

with zeros) 

[END ENCRYPTED AREA] 
15 2 bytes CRC 

This packet tracks all loyalty points awarded by a 

terminal. This packet should be generated each evening 

at midnight for the day's awards (or whenever the 

terminal detects the current day has changed) . 
20 Synchronization Packets 

Inventory 

Inventory packets have the following data structure: 

Field Size: Description: 

1 byte Packet Type = 0x83 

25 1 byte Packet Subtype = 0x00 

2 bytes Packet Size 
[BEGIN ENCRYPTED AREA] 

6 bytes Terminal ID issuing the request (or 0 for 

server inventories ) 
30 2 bytes System software version (LSB first) 

2 bytes Number of records (LSB first) (n) 

1 byte Table ID the record belongs to 

4 bytes Record ID 

35 2 bytes Number of files (LSB first) (m) 

4 bytes File ID (LSB first) 

2 bytes Number of content objects (LSB first) (m) 

4 bytes Content ID (LSB first) 



40 



• • • 

(Pad encrypted area to even multiple of 8 bytes) 
[END ENCRYPTED AREA] 
2 bytes CRC 
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Data is guaranteed to be in order of ascending 
table ID, but not necessarily in order of ascending 
record ID within each table ID. 
Table Download 

5 Downloaded table records are inserted directly into 

the database, using the record ID as a key* Any 
existing records with the same record ID are 
overwritten. A table download packet with 0 records is 
used to indicate no more data. 
10 Table download packets have the following data 

structure : 

Field Size: Description: 

1 byte Packet Type = 0x83 

1 byte Packet Subtype = 0x01 

25 2 bytes Packet Size 

[BEGIN ENCRYPTED AREA] 

1 byte Table ID being downloaded 

2 bytes Number of records (LSB first) (n) 

6 bytes Record ID of a record in the table (LSB 
20 first) 

2 bytes Record data size (in bytes, LSB first) 
Variable Record data 

(Pad encrypted area to even multiple of 8 bytes) 
25 [END ENCRYPTED AREA] 
2 bytes CRC 

File Initial Download 

File Initial Download packets have the following 
data structure: 

30 Field Size: Description: 

1 byte Packet Type = 0x83 

1 byte Packet Subtype = 0x02 

2 bytes Packet Size 
[BEGIN ENCRYPTED AREA] 

35 4 bytes File ID being downloaded (LBS first) 

4 bytes Total file size (LSB first) 

4 bytes File flags (compression info, permissions, 

etc, - TBD) 

2 bytes Number of segments (LSB first) 

40 1 byte Path length 

Variable pathname on local machine 

(Pad encrypted area to even multiple of 8-bytes) 
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[END ENCRYPTED AREA] 
2 bytes CRC 

File Next Download 

File Next Download packets have the following data 
5 structure : 

Field Size: Description: 

1 byte Packet Type = 0x83 

1 byte Packet Subtype = 0x03 

2 bytes Packet Size 
10 [BEGIN ENCRYPTED AREA] 

4 bytes File ID being downloaded (LBS first) 

2 bytes Segment number (LSB first) 

2 bytes Segment data size (LSB first) 

Variable Segment data 

15 (Pad encrypted area to even multiple of 8-bytes) 
[END ENCRYPTED AREA] 
2 bytes CRC 

File Initial Upload 

File Initial Upload packets have the following data 
20 structure: 

Field Size: Description: 

1 byte Packet Type = 0x83 

1 byte Packet Subtype = 0x04 

2 bytes Packet Size 
25 [BEGIN ENCRYPTED AREA] 

4 bytes File ID being uploaded (LBS first) 

4 bytes Total file size (LSB first) 

4 bytes File flags (compression info, permissions, ' 

etc, - TBD) 

30 2 bytes Number of Segments (LSB first) 

1 byte Filename length 

Variable Filename 

(Pad encrypted area to even multiple of 8-bytes) 
[END ENCRYPTED AREA] 
35 2 bytes CRC 

Retrieve File 

A request to transfer a file to a client if the 
client's version of the file is missing or out of date. 
Retrieve file request packets have the following data 
40 structure: 

Field Size: Description: 

1 byte Packet Type = 0x81 
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1 byte Packet Subtype = OxlF 

2 bytes Packet Size = 22 
[BEGIN ENCRYPTED AREA] 

1 byte File Type 

5 0 = Content 

1 = Service file 
4 bytes File ID 

4 bytes Current file size 

4 bytes Current file modification date 

10 2 bytes Current file CRC 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 

Retrieve File Response 

IS This packet is sent to the client immediately if 

the requested file is up to date, or does not exist, or 
after a series of file download packets if the file 
needs to be downloaded. 

Retrieve file request packets have the following 

20 data structure: 

Field Size: Description: 

1 byte Packet Type - 0x81 

1 byte Packet Subtype = 0x20 

2 bytes Packet Size = 22 
25 [BEGIN ENCRYPTED AREA] 

1 byte Status 

0 = File downloaded successfully 

1 = Current file is up to date 

2 = Error downloading 
30 3 = File not found 

4 = System error 
4 bytes File ID 

4 bytes Current file size 

4 bytes Current file modification date 

35 2 bytes Current file CRC 

(Pad encrypted area to even 8-byte boundary with zeros) 
[END ENCRYPTED AREA] 

2 bytes CRC 



40 For the synchronization function, assuming that the 

inventory of a customer is being downloaded, e.g. from 
a database associated with a regional server to a 
database associated with an arcade, public PC or 
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validation and redemption terminal, the packets can add 
a field (e.g. 4 bytes) which identifies the customer. 

The administration terminal 43 contains a database 
which specifies the entire system, in subdatabases 

5 which can be specified as classes* The content of the 
complete database, or the content of each subdatabase 
can be specified by a single administration entity, or 
any can be specified by authorized suppliers. In the 
latter case, the content of the subdatabases can be 

10 filled by communication between the terminal 43 and 

suppliers' terminals, using the system shown in Figure 
1. 

Subdatabases are preferred to relate to the 
following: 

15 Suppliers Locations 

Game Machines Game Software 

Redemptions Tournaments 
Merchandise Categories Pricing 
Prizes Alarms 
20 Schedules Manufacturers 
Customers Technicians 
Advertising Content 
Coupons Loyalty Programs 

Promotions Services 
25 Profile Descriptor (e.g. VALs) 

VAL™ is a standard profile descriptor which has 
been adopted by some companies.- VALs or class systems 
used by other companies can be stored and used in 
addition to or as a replacement for the demographic 
30 classification described herein. 

Game Software is an example of the above. A 
field of the above can be the identification of a game 
which is located on a CD ROM, hard disk drive, DVD or 
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mass semiconductor or other storage means at a game 
location. Another field can be an algorithm which 
controls the parameters of the game. Another field can 
store score brackets which a player must reach in order 
5 to win a prize. Another field can store timing 

information which can be used to modify the brackets. 
Other fields can be filled with other data required for 
the game . 

The other subdatabases can be similarly filled 

10 with data to specify the operation of each parameter of 
the system. For example, a merchant can specify a 
premium related to the merchant's store as a prize to 
the player of a game at an arcade nearby to the store. 
A field in the prize or coupon subdatabase can point to 

15 the game or games for which the premium or coupon is to 
be distributed, another can specify a score bracket to 
be achieved (which can be >0) by the player in order to 
win the premium or coupon, etc. 

Once the database has been completed to a 

20 required level, the subdatabases are downloaded to the 
decision support server 7, which stores it in its 
database 9. The decision support server then downloads 
the data as related to the various peripheral terminals 
to the associated regional servers, which in turn 

25 stores required data in their respective databases 5A 

to 5N, and downloads the data related to the respective 
terminals to those of concern. 

As a further example, regional server 5A 
downloads initialization parameters to the master games 

30 21 in the arcades in which authorized game machines are 
located which can communicate with the regional server 
5A. It also downloads initialization parameters to the 
software at the public PCs with which it can 
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communicate, which have been authorized at the 
administration location. 

For example, the initialization parameters may 
initialize or authorize operation of particular video 
5 games, with particular score brackets, at the arcade 17 
and at the public PC. The initialization parameters 
may also initialize a program at the public PC which 
controls acceptance of payments, and/or acceptance of 
orders for merchandise, and/or redemption of premiums, 
10 etc., and also controls transmission of data to the 
regional server which updates the account of the 
customer in currency or other media of exchange such as 
loyalty points, etc. 

Table 1 which is attached at the end of this 
15 specification describes preferred subdatabases to be 
established initially at the administration terminal, 
which specify games, software, advertisements and other 
matters, and their parameters, which are downloaded to 
the terminals in a manner as described above. Each of 
20 the subdatabases is headed by a table name, and each of 
the fields describes the content of the field; its 
content and use are self evident from the name chosen. 

It was noted above that parameters can be 
downloaded for the operation of a game. The shell of a 
25 game can have a requirement for score formulae to be 

inserted. The score formulae can be determined at the 
administration terminal, and downloaded as noted 
earlier, as one or more parameters of the game. 

For example, consider the Pacman tm game. Key 
30 graphical elements of the game are dots, fruits, 

ghosts, and the game requires a scope. These elements 
can be used in formulae; for example the dots can be 
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given a statistic S00, the fruits a statistic SOI, the 
ghosts a statistic S02 and the scope a statistic S03. 

A formula can be determined, e.g. (S00 + 5) * 
S03 to determine an output score for dots, for example. 

5 The formulae can be modified by a player rating, the 
player having been identified by his ID card that has 
been swiped. The formulae can be modified by the time 
of day, the number of games played in a certain time 
interval, the score brackets achieved by players in a 

10 certain time interval, etc. 

Indeed, a game can be refreshed by formulae 
which change the object of a game. An easy game can be 
made more difficult or different based on the formulae 
for a particular player profile. 

15 Loyalty points, coupons or other prizes can be 

awarded based on different formulae. These can be 
specified by different suppliers' terminals interacting 
with the administration terminal, or solely at the 
administration terminal . 

29 Prizes can be awarded based on a history of 
plays at a particular location. Par level and score 
brackets can be automatically adjusted. With reference 
to Figure 3, a histogram is shown of scores of a game 
against the number of plays achieving the scores. 

25 Within the region A, the top 10% of scores occur. 

Within the region B, the next 20% of scores occur, and 
within the region C, the next 30% of scores occur. A 
supplier determines, through the administration 
terminal, that the best prizes should be awarded for 

30 the scores in region A, the next best prizes for the 
scores in region B, and the lowest prize for the scores 
in region C. 
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The software can store the scores, and supply 
the scores to the game shell software to adjust the 
regions A, B and C, depending on how well and how many 
players play, and the history of prize redemptions at 
5 the particular game location, as specified by 

parameters input at the administration terminal. This 
can consist of adding the scores together, and if there 
have been prize redemptions in excess of a 
predetermined number established at the administration 
10 terminal, skewing the scores, or multiplying the 
scores, by a number or game handicap value. This 
process of skewing, in effect varies the shape and 
placement of the curve shown in Figure 4, and provides 
an automatic par or bracket adjustment for the game. 
i5 The software can also keep track of a player's 

score on a particular game and store it in the player's 
database, and can forbid the awarding of a prize to the 
player for a particular game within a certain time 
interval or within a certain arcade. This will stop a 
20 good player from collecting too many prizes or too 
large a prize on a single machine if the number of 
players is low, or if the player monopolizes a game. 

A key aspect of the system is to control the 
advertising shown to specific subscribers. Advertising 
25 can be shown in "slots", e.g. frames on a video game or 
public PC display. The administrator can specify 
advertisement types as indicated in the matrix of 
Figure 4 as "Ad Target Types to Play", i.e. types of 
ads for specific matched demographic player types. The 
30 first column in the matrix specifies "When To Play" . 

For example, when no player is present, 
advertisement types "0x00" followed by "Location 
Attract", followed by "Terminal Attract (for this 
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terminal's ID or a broadcast ID)" are specified. When 
an unidentified player is present (e.g. by detecting a 
body using an infrared detector) , but no service has 
been selected, an additional advertisement "0x01" is 

5 run immediately following advertisement "0x00". 

The entire matrix is filled out at an 
administrative location and is stored at the 
administration terminal 43 database, and once complete, 
it is downloaded to the decision support server 7, and 

10 stored in its database 9. It is then downloaded to the 
regional server, where it is stored in database 5A, and 
is downloaded to the master game 21, where it is stored 
in database 23. 

The master game 21 then controls the local DVD 

IS or CD ROM in accordance with the local condition (when 
to play) , to run the advertisements identified in the 
matrix. 

One of the parameters that can be used in an 
advertisement subdatabase is a demographic limit. For 

20 example, a field parameter can specify that playing of 
an advertisement for a toy doll can be logically nulled 
in the event that the location of the game, or the 
location of the identified player, is in a bar. This 
information can be downloaded with the initialization 

25 data for an advertisement and/or for a player. 

Once playing is initialized, the advertisement 
specified in the database matrix or the equivalent 
stored at the database 23 of the master game 21 is 
indicated to the game shell to be loaded from the DVD 

30 or CD ROM. The game shell inserts the advertisement 
into a time slot and window (or full screen) on the 
game (or public PC or other form of) display. Unless 
the presence of a player, identified or not, has been 
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detected (e.g. detected by an infrared detector, by 
swiping of a player's card in a card reader, by 
detection of a bar code of a coupon or premium by a bar 
code reader at a validation and redemption center, or 
5 by detection of a personal characteristic such as 

handwriting, voice, fingerprint, palmprint, iris, etc.) 
once display of the advertisement has been completed, 
the master game (or public PC) software accesses the 
database matrix or the equivalent and causes the next 
10 advertisement to run via the shell and be displayed. 

In the event the presence of a subscriber, or of 
an identified subscriber, is detected, the master game 
(or public PC) software accesses the advertisement 
matrix in the. database 23, and determines that a 
15 different schedule of advertisements should be run. It 
then indicates which is the first of the advertisements 
in this schedule, and causes it to run via the shell, 
as described above. 

It will be recognized that a player will 
20 typically interrupt an attraction mode advertisement by 
indicating that he wishes to play a game, e.g. by 
swiping his card in the card reader of a game, or by 
depositing coins in the coin acceptor of the game and 
keying in an identification code. The game software 
25 will then indicate this to the master game, which 
stores an indication in the indicated subscriber's 
database the identity of the last complete 
advertisement that the subscriber has seen. This is 
stored in the table "SUBSCRIBER_AD" , under "AD__ID" (See 
30 Table 1 located at the end of this specification) . 

When the subscriber is next indicated as being present 
at a viewable location, and is not playing a game, the 
next advertisement in the sequence indicated on the 
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matrix is controlled by the master game or public PC to 
be displayed. 

It will be noted from Table 1 that the record: 
table = "Ad_Target" contains fields which specify the 
5 minimum and maximum daily exposures, and the minimum 
and total daily exposures of an advertisement. These 
values can be based on sales of the advertisement, and 
are specified by the administrator. 

Considering the tables of the database relating 
10 to the advertising, in the table AD, 

- the first field RECORD_ID stores the record number, 

- the field AD_ID stores the identity of the 
advertisement, 

- the field CONTENT_ID identifies the file(s) that make 
15 up the advertisement (video clips, audio, image, etc.), 

- the field PRECEDING_AD_ID identifies the 
advertisement to be run immediately preceding this one, 

- the field NEXT_AD_ID identifies the advertisement to 
be run immediately following this one, 

20 - the field MAX_VTEWS_PERJPERSON specifies the maximum 
number of times the present advertisement should be 
shown to an identified subscriber, 

- the field FLAGS can be used to for various purposes, 
such as inhibiting a specified ad from playing e.g. 

25 inhibiting plays from bars, casinos, arcades, general 
audiences, men, women, male teens, female teens, etc. 

With the above detailed explanation of the first 
table, the remaining tables (records) and fields are 
believed to be self-explanatory from the names given to 
30 the tables and to each of the fields. 

It should also be noted that advertisements can 
be selected based on an algorithm. For example, a 
random number (e.g. between 0 and 9, say 5) can be 
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obtained from a random number generator. That random 
number 5 can identify e.g. a video or slide 
advertisement to be run. Following running, that 
random number can be added to another predetermined 

5 number {e.g. 3), to identify the next advertisement to 
be run, e.g. advertisement number 8. Following running 
of advertisement number 8, that number can be added to 
another predetermined number (e.g. 7), to identify the 
next advertisement to be run, e.g. advertisement number 

10 15, etc. The selection of which advertisement to run 
can cycle back to the beginning, or once a 
predetermined highest number has been reached, another 
random number can be selected and the process started 
again. 

25 it may be seen that the identity of 

advertisements that are selected for playing have been 
filtered through a schedule of particular 
advertisements. It is preferred that they should also 
be filtered by exclusions, for unsuitable 
20 advertisements. For example, cigarette advertisements 
or advertisements containing unsuitable subject matter 
can be excluded from certain locations, and 
competitor's products can be excluded from certain 
locations. These exclusions (URCs) can be stored in 
25 the table = ADJJRC. 

The field RECORD_ID in this table stores the 
record identity. The field AD_ID stores the identity 
of the advertisement against which the URC is to be 
applied. The URC can be comprised of a data field 
30 illustrated in Figure 5. 

The numeric value indicates the URC restriction 
code number. The bit in the flag indicates IS or NO, 
depending on whether it is set or not. The code (e.g. 
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the number 1/ 2, etc.) indicates the restriction. For 
example, the code 1 can mean "underage". Thus for 
example, if the advertisement indicated in the field 
AD_ID in the table AD_URC is unsuitable for a person 
5 under the age of 19, the flag is set (i.e. indicates 
IS) . If an underage person such as age 17 years (as 
can be indicated by his identity on e.g. the swipe card 
and his age statistic taken when the subscriber is 
first registered) is indicated as being at a particular 

10 location by him swiping his card at a validation and 
redemption center, a public PC or at a game in an 
arcade, for example, the advertisement is filtered 
through the URC, and is not shown for a time period. 
The time period can be a predetermined interval, or 

IS until a game played by the subscriber has been 
terminated, or can last for a time following 
termination of the game. 

It will be recognized that rather than 
advertisements, messages of any type can be provided 

20 for presentation to a person, and the URCs described 

above are equally applicable against such messages. In 
this specification, the term advertisements should thus 
be construed to include messages of any type, and 
presented in any way, such as by still picture, video, 

25 audio, etc. The term display should also be construed 
to include any form of presentation, including audio, 
video, tactile, odor dispersion, etc . 

A customer may attend a validation or redemption 
terminal location at the location of a merchant, or at 

30 an arcade, or at the location a public PC, and wish to 
enter credits, or wish to be registered in the system. 
Entering of credits can be effected by an attendant 
keying in relevant information to a terminal, 
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sufficient to identify the person, e.g. name and 
address, etc., or the customer can perform the same 
function via an automatic terminal such as a card 
vending machine which provides instructions how to 
5 proceed. If there are no credits to be entered, the 
customer should choose a PIN number, which is recorded 
in a hidden manner (such as in a magnetic stripe or in 
the memory of a "smart card" carried on the card) , and 
the card is dispensed or personally given to the 
10 customer. If a currency credit is to be posted, the 
customer will pay the attendant or deposit money into 
the card vending machine, which is recorded against the 
identity of the customer. The data entered into the 
terminal is then uploaded to the regional server e.g. 
25 1A/ and is stored in its associated database 5A. 

The customer now will undertake certain 
activities, such as purchasing goods or services from 
any of the merchants registered in the system, or play 
games at the arcade. If the customer plays games at 
20 the arcade, and wishes to use the credit balance in his 
account to play, he will swipe his card in a card 
reader at the game, which identifies him and the value 
to be debited from his balance. If he wishes to 
purchase goods or services against his credit, or 
25 purchase a different service offered at the public PC 
(e.g. purchase printing or communication services) his 
card will be swiped in a card reader at the location of 
the merchant where he wishes to purchase the goods or 
services or at the public PC. 
30 In any such case, the identity of the customer, 

the location of the customer, the identity of the 
merchant, game or public PC, and the amount of the 
debit will be uploaded into and stored in the database 
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5A after being recorded at the location (e.g. in 
database 23 if the transaction occurred at the arcade) . 

The administrator had already entered into its 
database using terminal 43 loyalty point values for 

5 certain activities, which had been downloaded and 
stored at database 9/ and then loaded to databases 
5A...5N. Therefore for each activity undertaken by the 
customer for which loyalty points are to be awarded, 
they are credited to the customer's account stored in 

10 the customer's database of the regional server. These 
loyalty points can then be used as a form of scrip by 
the customer, apart from, or with cash deposits. 

In addition, the administrator can specify and 
store records in the aforenoted databases that premium 

IS coupons should be dispensed for the customer at the 
determined location of the customer via a local 
printer, for defined activities undertaken by the 
customer . 

Loyalty points, game credits for future play 
20 and/or coupons can also be awarded to the account of 

the customer and/or dispensed when predetermined scores 
or score brackets are achieved on the games (whether 
due to individual play or in tournaments) by the 
identified customer player. 
25 The amounts of the loyalty points, game credits 

or coupons can be varied by time, by location, by 
number of players having played the game or tournament 
within a certain time interval or within certain clock 
times, by number of players, by demographic of the 
30 player, by difficulty of the game, by game handicap, 
etc. All such variations can be established at the 
administration location by means of a matrix (or form) 
to be filled in, such as shown in Table I attached 
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hereto and forming part of this specification, and 
stored in the databases as described above. Indeed, 
the administrator can indicate a conversion of loyalty 
points to currency, for redemption or for use to 
5 purchase goods of particular ones or of any goods or 
services provided by member merchants. 

When a customer wishes to redeem a coupon, the 
customer presents it to a merchant, public pc operator, 
public pc, etc., its bar code is read by a bar code 
10 reader at a validation and redemption terminal, and the 
customer's identification is read from his card by a 
card reader, at the validation and redemption terminal. 
The identification (and value, if desired for greater 
security) of the coupon is uploaded to the regional 
IS server, and the database is accessed using the 

identification of the customer. The identity of the 
coupon is then checked in the customer's record, and if 
the coupon had been validly recorded, a message is sent 
to the validation and redemption terminal acknowledging 
20 the validity of the transaction. An acknowledgement is 
entered into the terminal and is uploaded to the 
regional server,, which either marks the coupon record 
as having been used, or deletes it from the customer's 
record. In either case, information of the awarding, 
25 and subsequently of the redemption of the coupon, is 

entered to database 9 via the decision support server, 
to provide a statistical report to terminal 43 either 
immediately or from time to time as to volumes and 
identities of services used by the customer or by 
30 groups of customers, by demographics, etc. and coupons 
and loyalty points awarded and redeemed, and the 
identity of the merchant or terminal performing the 
redemption . 
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These statistics provide a good measure for the 
administrator to be able to use for reporting and/or 
advertising of the benefits of the system to 
prospective merchants and others which may wish to 

5 advertise on the system or which may wish to include 
their goods, services and locations as part of the 
system. In addition, it provides the information to 
the administrator for settling the merchants 1 accounts, 
as described earlier. The loyalty points thus have 

10 been used as a medium of exchange separate from 
currency. 

It should be noted that while the description 
herein is to a client-server type system which 
communicate in a particular manner, the equivalent 

IS function and structure of the invention could also be 
realized by persons skilled in the art understanding 
this invention via one or more browsers which interface 
one or more web pages, either via the internet or on 
one or more intranets which are either self-contained 

20 or which communicate via the internet or via private 
network. 

A person understanding this invention may now 
conceive of alternate embodiments and enhancements 
using the principles described herein. All such 
25 embodiments and enhancements are considered to be 
within the spirit and scope of this invention as 
defined in the claims appended hereto. 
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TABLE 1 



# initdb.ini 
# 

# NOTES: 

# 1. Database name cannot exceed 23 characters 

# 2. Allowed data type are LONG, SHORT, BIN, VARBIN 

# 3. Table names cannot exceed 23 characters 

# 4 . Field names cannot exceed 23 characters 

# 5. Arrays of SHORT and LONG are not supported (set 

size = 1) 

# 6. Variable binary fields as primary keys is not 

supported 

# 7 . Each table can have only one variable binary 

field 

# 8. Variable binary field must be last field in 

table 

# 9. Variable binary field must be preceded by SHORT 

size field 

# 10. File created will be database name with " .db" 

appended 

# 11. Tables cannot exceed 32 fields 



DATABASE = nani 



TABLE = AD 

FIELD = REC0RD_ID 

FIELD = AD_ID 

FIELD = CONTENT_ID 

FIELD = PRECEDING_AD_ID 

FIELD = NEXT_AD_ID 

FIELD = MAX_VIEWS_PER_PERSON 

FIELD = FLAGS 



BIN 

LONG 

LONG 

LONG 

LONG 

SHORT 

BIN 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 



AD_S CHEDULE 

RECORD_ID 

AD_ID 

TERMINAL_ID 
SCHEDULE_ID 
FLAGS 



BIN 

LONG 

BIN 

LONG 

BIN 



6 
1 
6 
1 
1 



TABLE = AD_TARGET 
FIELD = RECORD_ID 
FIELD = TARGET_ID 
FIELD = AD_ID 
FIELD = TARGET_TYPE 
FIELD = TARGET_EVENT_ID 
FIELD = TARGE T_S ERV I CE_ I D 
FIELD = SLOT 



BIN 

LONG 

LONG 

BIN 

LONG 

LONG 

BIN 
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FIELD 




PRIORITY : 


D TXT • 

BIN : 


1 


FIELD 




MIN DAILY EXPOSURES : 


SHORT : 


1 


FIELD 




MAX DAILY EXPOSURES : 


SHORT : 


1 


FIELD 




MIN_TOTAL_EXPOSURES : 


LONG : 


1 


FIELD 




MAX_TOTAL_EXPOSURES : 


LONG : 


1 


FIELD 


= 


FLAGS : 


T3 T XT . 

BIN : 


1 


TABLE 




AD TARGET DEMOGRAPHIC 






FIELD 


— 


RECORD ID : 


BIN : 


6 


FIELD 




TARGE T_ID : 


LONG : 


1 


FIELD 




DEMOGRAPHIC : 


LONG : 


1 


FIELD 




FLAGS : 


T"> TXT . 

BIN : 


1 


TABLE 




AD TARGET PROMOT I ON 






FIELD 




RECORD ID : 


BIN : 


6 


FIELD 


= 


TARGE T_ID : 


LONG : 


1 


FIELD 




PROMOT I ON I D : 


XjONG : 


1 


FIELD 




FLAGS : 


T~% TXT . 

BIN : 


1 


TABLE 




AD__URC 






FIELD 




RECORD ID : 


TXT * 

BIN : 


rr 
D 


FIELD 




AD__ ID : 


LONG : 


1 


FIELD 




URC : 


LONG 


1 


FIELD 




FLAGS : 


T~i T XT 

BIN 


-* 
1 


TABLE 




ALARM_HANDLER 






FIELD 




t~) TT* /""\T"> T""\ T T"\ 

RECORD^ID 


> "O TXT 

; din 


\ D 


FIELD 


= 


TTT\ \TT\T T 1~\ 

HANDLE R_ ID 


: LONG 


, i 

: l 


FIELD 




ALARM CODE 


» T3 TXT 


: i 


FIELD 




T r\"D T TV 
PRIORI T I 


n txt 


. 1 


£ lhiliU 




rKOUbob lift* 


• n txt 


1 


XTTTTT T\ 




ITT 7V/""0 


• DTM 

» D XiM 


» X 


TTTTTT "Pi 






► oflwrs.1 


. X 


ITTtTT T\ 






. v/U\D XIM 


• X 


TABLE 




rJKAUrviij 1 






TTTTTT T-\ 




KbLUKU ID 


ri X1n 


o 


ITTTTT T\ 
£ It, hi) 




TTNTTD XT7A X/TTT "NTT TTi 




X 


TTTTTT T^k 




noi\ryrT tti 




X 


TTT TTT T*\ 




C LT/^O T 1 XT7\TuflT 

o riUK 1 NAMiL 


HTM 


0 Q 
Z O 


FIELD 




XT TV XJTTT* 

NAME 


: bin 


• "7 O 

: / 2 


FIELD 




START DATE TIME 


: LONG 


: 1 


FIELD 




END DATE TIME 


: LONG 


: 1 


FIELD 




SCORE POSTING TIME 


: LONG 


: 1 


FIELD 




ENTRY PRICE 


: LONG 


: 1 


FIELD 




PREPAID PLAYS 


: SHORT 


: 1 


FIELD 




MIN GAMES PER PLAYER 


: SHORT 


: 1 


FIELD 




MAX GAMES PER PLAYER 


: SHORT 


: 1 


FIELD 




MIN GAMES PER TEAM 


: SHORT 


: 1 


FIELD 




MAX GAMES PER TEAM 


: SHORT 


: 1 
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FIELD = LEADERBOARD_ID : LONG 

FIELD = SPONSER : BIN 

FIELD = ICON : LONG 

FIELD = SPLASH_SCREEN : LONG 

FIELD = FLAGS : BIN 

FIELD = RANKING_ALGORITHM : BIN 

TABLE = BRACKET_ADVANCE 

FIELD = RECORD_ID : BIN 

FIELD = TOURNAMENT_ID : LONG 

FIELD = BRACKET_ID : BIN 

FIELD = ADVANCE_TYPE : BIN 

FIELD = FROM_TOURNAMENT_ID : LONG 

FIELD = FROM_BRACKET_ID : BIN 

FIELD = FROM_LOW : LONG 

FIELD = TO_HIGH : LONG 

FIELD = SERVICE_ID : LONG 

FIELD = PROFILE : BIN 

FIELD = FLAGS : BIN 

TABLE = BRACKE T_MEMBERS HIP 

FIELD = RECORD_ID : BIN 

FIELD = TOURNAMENT_ID : LONG 

FIELD = BRACKE T_ ID : BIN 

FIELD = SUBSCRIBER_ID : LONG 

FIELD = FLAGS : BIN 

TABLE = BRACKET_PRIZE 

FIELD = RECORD_ID : BIN 

FIELD = TOURNAMENT_ID : LONG 

FIELD = BRACKE T_ID : BIN 

FIELD = PRIZE_ITEM_ID : LONG 
FIELD = PRIZE_PERCENT_OF_POOL : BIN 

FIELD = WINNING_PLACE : BIN 

FIELD = PLACE_NAME : BIN 

FIELD = NUM_WINNERS : LONG 

FIELD = EXP I RAT I ON_DATE : LONG 

FIELD = FLAGS : BIN 

TABLE = BRACKET_PROMOTION 

FIELD = RECORD_ID : BIN 

FIELD = TOURNAMENT_ID : LONG 

FIELD = BRACKE T_ID : BIN 

FIELD = PROMOTION_ID : LONG 

FIELD = FLAGS : BIN 

FIELD = MIN_RANK : SHORT 

TABLE = BRACKET_RULE_S CREEN 

FIELD = RECORD_ID : BIN 
FIELD = TOURNAMENT ID : LONG 
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FIELD = BRACKET_ID 

FIELD = SERVICE_ID 

FIELD = SCREEN_INDEX 

FIELD = CONTENT_ID 

FIELD = FLAGS 



BIN 

LONG 

BIN 

LONG 

BIN 



1 
1 
1 
1 
1 



TABLE = BRACKET_SCHEDULE 

FIELD = RECORD_ID 

FIELD = TOURNAMENT_ID 

FIELD = BRACKET_ID 

FIELD = TERMINAL_ID 

FIELD = SCHEDULE_ID 

FIELD = FLAGS 

FIELD = NUM LOCAL LEADERS 



BIN 

LONG 

BIN 

BIN 

LONG 

BIN 

SHORT 



6 
1 
1 
6 
1 
1 
1 



TABLE = BRACKET_SERVICE 
FIELD = RECORD_ID 
FIELD = TOURNAMENT_ID 
FIELD = BRACKET_ID 
FIELD = SERVICE_ID 
FIELD = PROFILE 
FIELD = PRICING_ID 
FIELD = FLAGS 

FIELD = MIN_RATING_ALLOWED 
FIELD = MAX RATING ALLOWED 



BIN 

LONG 

BIN 

LONG 

BIN 

LONG 

BIN 

BIN 

BIN 



6 
1 
1 
1 
1 
1 
1 

1 . 
1 



TABLE = CATALOG_CATEGORY 

FIELD = RECORD_ID 

FIELD = CATEGORY_ID 

FIELD = CATEGORY_NAME 

FIELD = PARENT_CATE GOR Y_ I D 

FIELD = ICON 

FIELD = FLAGS 



BIN 

LONG 

BIN 

LONG 

LONG 

BIN 



6 : 
1 

40 
1 
1 
1 



TABLE = CATALOG_CATEGORY_URC 
FIELD = RECORD_ID 
FIELD = CATEGORY_ID 
FIELD = URC 
FIELD = FLAGS 



BIN 
LONG 
LONG 
BIN 



6 
1 
1 
1 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 



CONTENT 

RECORD_ID 

CONTENT_ID 

FORMAT 

DURAT I ON_MS 

PATHNAME 

FILE_SIZE 

CRC 

FILEJTIME STAMP 
FLAGS 



BIN 

LONG 

BIN 

LONG 

BIN 

LONG 

SHORT 

LONG 

BIN 



6 
1 
1 
1 

60 

1 

1 

1 

1 
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TABLE = COUPON 

FIELD = RECORD_ID : BIN 

FIELD = COUPON- ID : LONG 

FIELD = DESCRIPTION : BIN 

FIELD = CONTENT_ID : LONG 

FIELD = UPC_SYMBOL : BIN 

FIELD = FACE_VALUE : LONG 
FIELD = MAX_I S SUED_PER_P LAYER : SHORT 

FIELD = FLAGS = BIN 

TABLE = COUPON_ITEM_SCHEDULE 

FIELD = RECORD_ID : BIN 

FIELD = COUPON_ID : LONG 

FIELD = ITEM_ID LONG 

FIELD = TERMINAL_ID : BIN 

FIELD = SCHEDULE_ID : LONG 

FIELD = COUPON_CASH_VALUE : LONG 

FIELD = COUPON_PRICE : LONG 

FIELD = NUM_ITEMS_PER_COUPON : SHORT 

FIELD = MAXJREDEEMED : SHORT 

FIELD = FLAGS : BIN 

TABLE = COUPON_SERVICE_SCHEDULE 

FIELD = RECORD_ID : BIN 

FIELD = COUPON_ID : LONG 

FIELD = SERVICE_ID : LONG 

FIELD = TERMINAL_ID : BIN 

FIELD = SCHEDULE_ID : LONG 

FIELD = COUPON_CASH_VALUE : LONG 

FIELD = COUPONJPRICE : LONG 
FIELD = NUM_PLAYS_PER_COUPON : SHORT 

FIELD = MAX_REDEEMED : SHORT 

FIELD = FLAGS : BIN 

TABLE = FILE_INF0 

FIELD = RECORD_ID : BIN 

FIELD = FILE_ID : LONG 

FIELD = FILESET_ID : LONG 

FIELD = PATHNAME : BIN 

FIELD = FILE_SIZE : LONG 

FIELD = CRC : SHORT 

FIELD = FILE_TIMESTAMP : LONG 

FIELD = FLAGS : BIN 

TABLE = ITEM 

FIELD = RECORD_ID : BIN 

FIELD = ITEM_ID : LONG 

FIELD = CATEGORY_ID : LONG 

FIELD = I TEM_NAME : BIN 

FIELD = MIN PRICE : LONG 
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FIELD 




MAX PRICE : 


LONG : 


1 


FIELD 




ICON 


LONG : 


1 


FIELD 




FLAGS 


BIN : 


1 


FIELD 




ITEM COST 


: LONG : 


: 1 


FIELD 




RETAIL PRICE 


: LONG : 


: 1 


FIELD 




QUANTITY ON HAND 


: LONG 


: 1 


FIELD 




MIN QUANTITY ON HAND 


: LONG 


: 1 


FIELD 




DISTRIBUTION LOCATION 


: BIN 


: 40 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 



I TEM_ATTRIBUTE 

RECORD_ID 

ITEM_ID 

ATTRIBUTE_ID 

ATTRIBUTE_NAME 

DATA_TYPE 

MINIMUM 

MAXIMUM 

FLAGS 



BIN 

LONG 

BIN 

BIN 

BIN 

LONG 

LONG 

BIN 



6 
1 
1 

40 

1 

1 

1 

1 



PK 



TABLE = I TEM_ATTRI BUTE_VALUE 

FIELD = RECORD_ID 

FIELD = I TEM_I D 

FIELD = ATTRIBUTE_ID 

FIELD = VALUE_ INDEX 

FIELD = VALUE_TEXT 

FIELD = FLAGS 



BIN 

LONG 

BIN 

BIN 

BIN 

BIN 



6 : 
1 
1 
1 

30 
1 



PK 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 



ITEM_PROMOTION 

RECORD_ID 

ITEM_ID 

PROMOTION_ID 

FLAGS 



BIN 
LONG 
LONG 
BIN 



6 
1 
1 
1 



PK 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 



I TEM_S CHEDULE 

RECORD_ID 

ITEM_ID 

TERMINAL_ID 

SCHEDULE_ID 

FLAGS 



BIN 

LONG 

BIN 

LONG 

BIN 



6 
1 
6 
1 
1 



PK 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 



ITEM_SCREEN 

RECORD_ID 

ITEM_ID 

SCREEN_INDEX 

CONTENT_ID 

FLAGS 



BIN 

LONG 

BIN 

LONG 

BIN 



6 
1 
1 
1 
1 



PK 



TABLE 
FIELD 
FIELD 



ITEM_URC 
RECORD_ID 
ITEM ID 



BIN 
LONG 



6 
1 



PK 
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TABLE = LEADERBOARD 

FIELD = RECORD_ID : BIN 

FIELD = LEADERBOARD_I D : LONG 
FIELD = LEADERBOARD_DATE_T IME : LONG 

FIELD = FLAGS : BIN 

FIELD = MAX_LEADERS : SHORT 

TABLE = LEADERBOARD_LEADER 

FIELD = RECORD_ID : BIN 

FIELD = LEADERBOARD_ID : LONG 

FIELD = SUBSCRIBER_ID : LONG 

FIELD = ALIAS : BIN 

FIELD = LOCAT I ON_NAME : BIN 

FIELD = LOCAT I ON_C I T Y_S TATE : BIN 

FIELD = PRI ZE_NAME : BIN 

FIELD = SCORE : LONG 

FIELD = S CORE_DATE_T IME : LONG 

FIELD = FLAGS : BIN 

TABLE = LEADERBOARD_RANKING 

FIELD = RECORD_ID : BIN 

FIELD = LEADERBOARD_ID : LONG 

FIELD = RANK : SHORT 

FIELD = SUBSCRIBER_ID : LONG 

FIELD = FLAGS : BIN 

TABLE = LOCATION 

FIELD = RECORD_ID : BIN 

FIELD = LOCAT ION_ID : LONG 

FIELD = SHORT_NAME : BIN 

FIELD = NAME : BIN 

FIELD = SHORT_C I T Y_S TATE : BIN 
FIELD = CITY_STATE : BIN 

FIELD = TIME_ZONE : BIN 

FIELD = MAX_DAILY_PAYOUT : LONG 

FIELD = DIALIN_INTERVAL : LONG 

FIELD = LANGUAGE_CODE : SHORT 

FIELD = COUNTRY_CODE : SHORT 

FIELD = FLAGS : BIN 

FIELD = TOKEN_PRICE : LONG 

TABLE = LOCAT I ON_AT TRACT_S CREEN 

FIELD = RECORD_ID : BIN 

FIELD = LOCATION_ID : LONG 

FIELD = SCREEN_INDEX : BIN 

FIELD = CONTENT_ID : LONG 

FIELD = FLAGS : BIN 
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TABLE = LOCATION_COUPON_SCHED 

FIELD = RECORD_ID 

FIELD = LOCATION_ID 

FIELD = COUPON_ID 

FIELD = SCHEDULE_ID 

FIELD = COUPON_PRICE 

FIELD = FLAGS 



BIN 

LONG 

LONG 

LONG 

LONG 

BIN 



6 
1 
1 
1 
1 
1 



PK 



TABLE = LOCAT ION_LOYALTY_SCHED 

FIELD = RECORD_ID 

FIELD = LOCATION_ID 

FIELD = LOYAL TY_PROGRAM_I D 

FIELD = SCHEDULE_ID 

FIELD = POINT_PRICE 

FIELD = FLAGS 



BIN 

LONG 

LONG 

LONG 

LONG 

BIN 



6 
1 
1 
1 
1 
1 



PK 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 



LOCATION_URC 

RECORD_ID 

LOCAT ION_ID 

URC 

FLAGS 



BIN 
LONG 
LONG 
BIN 



6 
1 
1 
1 



PK 



TABLE = LOYALTY_PROGRAM 

FIELD = RECORD_ID 

FIELD = LOYAL TY_PROGRAM_I D 

FIELD = NAME 

FIELD = POINT_LABEL 

FIELD = FLAGS 



BIN 

LONG 

BIN 

BIN 

BIN 



6 
1 

40 
20 
1 



TABLE = LOYALTY_ITEM_SCHED 

FIELD = RECORD_ID 

FIELD = LOYALT Y_PROGRAM_I D 

FIELD = ITEM_ID 

FIELD = TERM I NAL_ I D 

FIELD = SCHEDULE_ID 

FIELD = POINT_CASH_VALUE 

FIELD = POINT_PRICE 

FIELD = POINT_PER_ITEM 

FIELD = ITEMS_PER_POINT 

FIELD = MAX_USED_PER_I TEM 

FIELD = FLAGS 



BIN : 


6 


LONG : 


1 


LONG : 


1 


BIN : 


6 


LONG : 


1 


LONG : 


1 


LONG 


1 


SHORT 


• 1 


SHORT 


: 1 


SHORT 


: 1 


BIN 


: 1 



PK 



TABLE = LOYALT Y_SERVICE_SCHED 

FIELD = RECORD_ID 

FIELD = LOYALT Y_PROGRAM_ID 

FIELD = SERVICE_ID 

FIELD = TERMINAL_ID 

FIELD = SCHEDULE_ID 

FIELD = POINT_CASH^VALUE 

FIELD = POINT PRICE 



BIN 

LONG 

LONG 

BIN 

LONG 

LONG 

LONG 



6 
1 
1 
6 
1 
1 
1 



PK 
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FIELD = POINTS_PER_PLAY : SHORT 

FIELD = PLAYS_PER_POINT : SHORT 

FIELD = MAX_USED_PER_PLAY : SHORT 

FIELD = FLAGS : BIN 

TABLE = PRICING 

FIELD = RECORD_ID : BIN 

FIELD = PRICING_ID : LONG 

FIELD = PRICE_TO_START : LONG 

FIELD = PRICE_TO_CONTINUE : LONG 

FIELD = S TART_DURAT I ON : LONG 

FIELD = CONT I NUE_DURAT I ON : LONG 

FIELD = FLAGS : BIN 

TABLE = PROMOTION 

FIELD = RECORD_ID : BIN 

FIELD = PROMOTION_ID : LONG 

FIELD = FLAGS : BIN 

TABLE = PROMOTION_COUPON 

FIELD = RECORD_ID : BIN 

FIELD = PROMOTION_ID : LONG 

FIELD = COUPON_ID_TO_AWARD : LONG 

FIELD = FLAGS : BIN 

TABLE = PROMOT I ON_LOYALT Y 

FIELD = RECORD_ID : BIN 

FIELD = PROMOTION_ID : LONG 

FIELD = LOYALTY_PROGRAM_ID : LONG 

FIELD = NUM_POINTS_TO_AWARD : SHORT 

FIELD = FLAGS : BIN 

TABLE = REDEMPTION 

FIELD = RECORD_ID : BIN 

FIELD = REDEMPTION_ID : LONG 

FIELD = FLAGS : BIN 

FIELD = MIN_RATING_ALLOWED : BIN 

FIELD = MAX_RAT I NG_ALLOWED : BIN 

FIELD = SERVICE_ID : LONG 

FIELD = PROFILE : BIN 

FIELD = SHORT_NAME : BIN 

FIELD = NAME : BIN 

FIELD = PRICING_ID : LONG 

FIELD = S TART_DATE_T I ME : LONG 

FIELD = END_DATE_TIME : LONG 

FIELD = SPONSER : BIN 

FIELD = ICON : LONG 

FIELD = SPLASH_SCREEN : LONG 
FIELD = PERCENT_MONEY_TO_POOL : BIN 

FIELD = CURRENT POOL VALUE : LONG 
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FIELD = VALUE_OF_AVAIL_PRIZES : LONG 

FIELD = PLAYS_TOJDATE : LONG 

FIELD = LAS T_U P DATE_DAT E_T IME : LONG 

TABLE = REDEMPT I ON_PAR_LEVEL 

FIELD = RECORD_ID : BIN 

FIELD = REDEMPT I ON_ID : LONG 

FIELD = PAR_LEVEL : BIN 

FIELD = PAR_SCORE : LONG 

FIELD = TARGET_PAY_PERCENT : BIN 

FIELD = PRIZE_ITEM_ID : LONG 
FIELD = PERCENT_OF_POOL_APPLIED : BIN 

FIELD = EXPIRATIONJDATE : LONG 

FIELD = NUMJREMAINING : LONG 

FIELD = MIN_WIN_INTERVAL : LONG 

FIELD = FLAGS : BIN 

FIELD = MIN_PRIOR_PLAYS : LONG 

TABLE = RE DEMPT I ON_PROMOT I ON 

FIELD = RECORD_ID : BIN 

FIELD = REDEMPT ION_ID : LONG 

FIELD = PROMOTION_ID : LONG 

FIELD = FLAGS : BIN 

FIELD = PAR_LEVEL : BIN 

TABLE = REDEMPTION_RULE_SCREEN 

FIELD = RECORD_ID : BIN 

FIELD = REDEMPT I ON_ID : LONG 

FIELD = SCREEN_INDEX : BIN 

FIELD = CONTENT_ID : LONG 

FIELD = FLAGS : BIN 

TABLE = REDEMPT I ON_SCHEDULE 

FIELD = RECORD_ID : BIN 

FIELD = REDEMPT ION_ID : LONG 

FIELD = TERMINAL_ID : BIN 

FIELD = SCHEDULE_ID : LONG 

FIELD = FLAGS : BIN 

TABLE = REDEMPT I ON_URC 

FIELD = RECORD_ID : BIN 

FIELD = REDEMPT I ON_ID : LONG 

FIELD = URC : LONG 

FIELD = FLAGS : BIN 

TABLE = SCHEDULE 

FIELD = RECORD_ID : BIN 

FIELD = SCHEDULE_ID : LONG 

FIELD - S TART_DATE_T IME : LONG 

FIELD = END DATE TIME : LONG 
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FIELD 




WEEKDAYS : 


BIN : 


1 


FIELD 




START TIME OF DAY 


LONG : 


1 


FIELD 




END TIME OF DAY : 


LONG 


1 


FIELD 




FLAGS : 


BIN : 


1 


TABLE 




SERVICE 






FIELD 




RECORD_ID : 


T3 TXT . 

BIN : 


6 : 


FIELD 




SERVICE ID : 


LONG : 


1 


FIELD 


= 


SERVICE TYPE : 


BIN : 


1 


FIELD 




FLAGS : 


BIN : 


1 


FIELD 




SHORT_NAME : 


D TXT • 

BIN : 


J 0 


FIELD 




NAME : 


BIN : 


72 


FIELD 




ICON : 


LONG : 


1 


FIELD 


= 


ATTRACT SCREEN : 


LONG : 


1 


FIELD 




SW_CAPABILITIES : 


BIN : 


10 


FIELD 




Hw REQUIREMENTS : 


BIN : 


1 0 


FIELD 




FILESET ID : 


LONG : 


1 


FIELD 





EXECUTABLE_FILE_ID : 


LONG : 


1 


TABLE 




SERVICE PROFILE 






FIELD 




RECORD_ID : 


: BIN ; 


6 


FIELD 




SERVICE_ID : 


: LONG : 


: 1 


FIELD 




PROFILE 


: BIN 


: 1 


FIELD 




PROFILE NAME 


: BIN 


: 40 


FIELD 




■f— »T TV O 

FLAGS 


> O TXT 

: BIN 


: 1 


FIELD 


— 


SCORE FORMULA LENGTH 


: SHORT 


: 1 


FIELD 


— 


SCORE_FORMULA 


: VARBIN 


: 1 


TABLE 










FIELD 




KtiUUKD XD 


• DTTiT 

I tiXJNI 


I 0 


TTTTTT 

r LiLLtU 






• t r\ur* 
-LUJNo 




FIELD 


— 


PROFILE - 


: BIN 


: 1 


FIELD 




SETTING_ID 


: LONG 


: 1 


TTTTTT Ti 




oLi 1 UNb V i-LLi U ill 


• T OMP 


X 


TTTTTT 








X 


IAdLiL. 




orjKyx^JL jrr\VJjyivJ 1 XUJN 










Kr*UUKiJ 1U 


• Xi T*KT 


D 


TT'T TP T T"\ 

FIELD 




"COT TT ^TT T T"\ 


• T /"VNT/"' 

: JjONCj 


: x 


FIELD 




PROMOTION ID 


: LONG 


: 1 


FIELD 




FLAGS 


: BIN 


: 1 


TABLE 




SERVICE RATING 






FIELD 




RECORD ID 


: BIN 


: 6 


FIELD 




SERVICE ID 


: LONG 


: 1 


FIELD 




RATING 


: BIN 


: 1 


FIELD 




DESCRIPTION 


: BIN 


: 26 


FIELD 




FLAGS 


: BIN 


: 1 



PK 



PK 



PK 



PK 



PK 
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TABLE 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 



SERVICE_SCHEDULE 

RECORD_ID 

SERVICE_ID 

TERMINAL_ID 

SCHEDULE_ID 

PROFILE 

PRICING_ID 

FLAGS 



BIN 

LONG 

BIN 

LONG 

BIN 

LONG 

BIN 



6 
1 
6 
1 
1 
1 
1 



PK 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 



SERVICE_SETTING 

RECORD_ID 

SERVICE_ID 

SETTING_ID 

SETTING_NAME 

TYPE 

FLAGS 



BIN 

LONG 

LONG 

BIN 

BIN 

BIN 



6 : 

1 

1 

32 

1 

1 



PK 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 



SERVICE_SLOT 
RECORD_ID 
SERVICE_ID 
SLOT 

SCHEDULE_ID 
NUM_AD_P LAY S 
FLAGS 



BIN 

LONG 

BIN 

LONG 

BIN 

BIN 



6 
1 
1 
1 
1 
1 



PK 



TABLE - SERVICE_STATISTIC 

FIELD = RECORD_ID 

FIELD = SERVICE_ID 

FIELD = STATISTIC_ID 

FIELD = S TAT I S T I C_NAME 

FIELD = LOWER_LIMIT 

FIELD = UPPER_LIMIT 

FIELD = FLAGS 



BIN 

LONG 

LONG 

BIN 

LONG 

LONG 

BIN 



6 : 

1 

1 

20 
1 
1 
1 



PK 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 



SERVICE_TERMINAL 

RECORD_ID 

SERVICE_ID 

TERMINAL_ID 

L I CENS E_KE Y 

FILESET_ID 

FLAGS 



BIN 

LONG 

BIN 

BIN 

LONG 

BIN 



6 : 

1 

6 

16 

1 

1 



PK 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 
FIELD 



SERVICE_TYPE 

RECORD_ID 

TYPE 

PARENT_TYPE 

TYPE_NAME 

FLAGS 



BIN 
BIN 
BIN 
BIN 
BIN 



6 : 

1 

1 

16 
1 



PK 
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TABLE = SERVICE_URC 

FIELD = RECORD_ID : BIN 

FIELD = SERVICE_ID : LONG 

FIELD = URC : LONG 

FIELD = FLAGS : BIN 

TABLE = SUBSCRIBER 

FIELD = RECORD_ID : BIN 

FIELD = SUBSCRIBER_ID : LONG 

FIELD = ALIAS : BIN 

FIELD = FIRST_NAME : BIN 

FIELD = LAST_NAME : BIN 

FIELD = MIDDLE_INITIAL : BIN 

FIELD = STREET_ADDRESS : BIN 

FIELD = POSTAL_CODE : BIN 

FIELD = PHONE_NUMBER : BIN 

FIELD = BIRTH_DAY : BIN 

FIELD = BIRTH_MONTH : BIN 

FIELD = BIRTH_YEAR : SHORT 

FIELD = GENDER : BIN 

FIELD = FLAGS : BIN 

FIELD = DEMOGRAPHIC : LONG 
FIELD = LAS T_UPDATE_DATE_T IME : LONG 

TABLE = SUB S CR I BER_AD 

FIELD = RECORD_ID : BIN 

FIELD = SUBSCRIBER_ID : LONG 

FIELD = AD_ID : LONG 

FIELD = VIEW_DATE_T IME : LONG 

FIELD = FLAGS : BIN 

TABLE = SUBSCRIBER_AVATAR 

FIELD = RECORD_ID : BIN 

FIELD = SUBSCRIBER_ID : LONG 

FIELD = AVATAR_TYPE : BIN 

FIELD = CONTENT_ID : LONG 

FIELD = FLAGS : BIN 

TABLE = SUBSCRIBER_BRACKET 

FIELD = RECORD_ID : BIN 

FIELD = SUBSCRIBER_ID : LONG 

FIELD = TOURNAMENT_ID : LONG 

FIELD = BRACKET_ID : BIN 

FIELD = GAME S_P LAY E D : SHORT 

FIELD = FLAGS : BIN 

FIELD = RANK : LONG 

FIELD = RANK_DATE_T IME : LONG 

FIELD = RANK_S CORE : LONG 

FIELD = AVERAGE SCORE : LONG 
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TABLE 




SUBSCRIBER CARD 








FIELD 


_ 


RECORD ID : 


BIN : 


6 : 


PK 


FIELD 


_ 


SUBSCRIBER ID : 


LONG : 


1 




FIELD 


— 


CARD TYPE : 


BIN : 


1 




FIELD 


— 


CARD DATA : 


BIN : 


16 




FIELD 




FLAGS : 


BIN : 


1 




TABLE 


Z 


SUBSCRIBER RATING 








FIELD 




RECORD ID : 


BIN : 


6 : 


PK 


FIELD 




SUBSCRIBER ID : 


LONG : 


1 




FIELD 




SERVICE ID : 


LONG : 


1 




FIELD 


— 


PROFILE : 


BIN : 


1 




FIELD 


_ 


RATING : 


BIN : 


1 




FIELD 


_ 


HANDICAP : 


LONG : 


1 




FIELD 


_ 


PLAYS TO QUALIFY : 


BIN : 


1 




FIELD 


_ 


FLAGS : 


BIN : 


1 




TABLE 




SUBSCRIBER SAVE STATE 








FIELD 




RECORD ID : 


BIN : 


6 : 


PK 


FIELD 





SUBSCRTBER ID : 


LONG : 


1 




FIELD 





SERVICE ID~ : 


LONG : 


1 




FIELD 





SLOT NUMBER 


BIN 


1 




FIELD 




PROFILE 


: BIN 


: 1 




FIELD 


= 


SAVE STATE NAME 


: BIN 


: 20 




FIELD 




DATA FILE ID 


: LONG 


: 1 




FIELD 


__ 


FLAGS 


: BIN 


: 1 




TABLE 


— 


SUBSCRIBER URC 








FIELD 




RECORD_ID 


: BIN 


: 6 : 


PK 


FIELD 




SUBSCRIBER ID 


T AMP 

: LONG 


: 1 




FIELD 




URC 


: LONG 


: 1 




FIELD 


— 


FLAGS 


: BIN 


: 1 




TABLE 




TEAM MEMBER 








FIELD 




RECORD ID 


: BIN 


: 6 : 


PK 


FIELD 


= 


TEAM_SUBSCRIBER_ID 


: LONG 


: 1 




FIELD 




SUBSCRIBER ID 


: LONG 


: 1 




FIELD 




FLAGS 


: BIN 


: 1 




TABLE 


= 


TECHNICIAN 








FIELD 


— 


RECORD ID 


: BIN 


: 6 : 


PK 


FIELD 




TECHNICIAN ID 


: LONG 


: 1 




FIELD 




NAME 


: BIN 


: 26 




FIELD 




PIN 


: SHORT 


: 1 




FIELD 




FLAGS 


: BIN 


: 1 




TABLE 




TECHNICIAN TERMINAL 








FIELD 




RECORD ID 


: BIN 


: 6 : 


PK 


FIELD 




TECHNICIAN ID 


: LONG 


: 1 




FIELD 




TERMINAL ID 


: BIN 


: 6 
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FIELD = AUTHORIZATION FLAGS 



: BIN 



TABLE = TERMINAL 
FIELD = RECORD_ID 
FIELD = TERMINAL_ID 
FIELD = LOCATION_ID 
FIELD = LAN_ADDRESS 
FIELD = FLAGS 
FIELD = SERIAL_NUMBER 
FIELD = HW_CAPABILITIES 
FIELD = ATTRACT_SCREEN 
FIELD = SYSTEM FILESET ID 



BIN 

BIN 

LONG 

BIN 

BIN 

BIN 

BIN 

LONG 

LONG 



6 : 

6 

1 

4 

1 

20 
10 
1 
1 



PK 



TABLE = TOURNAMENT 
FIELD = RECORD_ID 
FIELD = TOURNAMENT_ID 
FIELD = SHORT_NAME 
FIELD = NAME 
FIELD = S TART_DATE_T IME 
FIELD = END_DATE_T IME 
FIELD = TOURNAMENT_SCOPE 
FIELD = FLAGS 
FIELD « SPONSER 
FIELD = ICON 
FIELD = SPLASH_SCREEN 
FIELD = PERCENT_MONEY__TO_POOL 
FIELD = CURRENT_POOL_VALUE 
FIELD = PLAYS_TO_DATE 
FIELD = LAST UPDATE DATE TIME 



BIN 

LONG 

BIN 

BIN 

LONG 

LONG 

BIN 

BIN 

BIN 

LONG 

LONG 

BIN 

LONG 

LONG 

LONG 



6 : 

1 

28 

72 

1 

1 

1 

1 

40 

1 

1 

1 

1 

1 

1 



PK 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 



TOURNAMENT_URC 

RECORD_ID 

TOURNAMENT_ID 

URC 

FLAGS 



BIN 
LONG 
LONG 
BIN 



6 
1 
1 
1 



PK 



TABLE = URC_VALUE 
FIELD = RECORD_ID 
FIELD = URC 

FIELD = RESTRICTED_STRING 
FIELD = FLAGS 



BIN 
LONG 
BIN 
BIN 



6 : 
1 

30 
1 



PK 



# Working tables - not replicated from EDS server 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 



W_AD_EXPOSURE 
RECORD_ID 
TARGE T_ ID 
SUBSCRIBER_ID 
PLAY DATE TIME 



LONG 
LONG 
LONG 
LONG 



1 
1 
1 
1 
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TABLE = W_AD_EXPOSURE_COUNTS 
FIELD = RECORD_ID 
FIELD = TARGET_ID 
FIELD = TOTAL_PLAYS_TODAY 
FIELD = TOTAL PLAYS TO DATE 



LONG 
LONG 
SHORT 
LONG 



TABLE 
FIELD 
FIELD 
FIELD 
FIELD 



W_CONTENT_CACHE 
RECORD_ID 
CONTENT_ I D 
LOCAL_PATH_S I ZE 
LOCAL PATH 



LONG 
LONG 
SHORT 
VARBIN 



TABLE = W COUPONS ISSUED 



FIELD = RECORD_ID : LONG 

FIELD = COUPON_ID : LONG 

FIELD = RECEIPT_ID : BIN 

FIELD = TERMINAL_ID : BIN 

FIELD = SUBSCRIBER_ID : LONG 

FIELD = I S SUE_DATE_T I ME : LONG 

FIELD = FLAGS : BIN 

TABLE = W_DOWN_T I ME 

FIELD = RECORD_ID : LONG 

FIELD = S TART_DATE_T IME : LONG 

FIELD = END_DATE_T IME : LONG 

FIELD = TECHNIC I AN_ID : LONG 

TABLE = W_FILE_CACHE 

FIELD = RECORD_ID : LONG 

FIELD = FILE_ID : LONG 

FIELD = LOCAL_PATH_SIZE : SHORT 

FIELD = LOCAL_PATH : VARBIN 

TABLE = W_LEADERBOARD 

FIELD = RECORD_ID : LONG 

FIELD = LEADERBOARD_ID : LONG 

FIELD = LEADERBOARD_DATE_TIME : LONG 

FIELD = FLAGS : BIN 

FIELD = MAX_LEADERS : SHORT 

TABLE = W_LEADERBOARD_LEADER 

FIELD = RECORD_ID : LONG 

FIELD = LEADERBOARD_ID : LONG 

FIELD = SUBSCRIBER_ID : LONG 

FIELD = ALIAS : BIN 

FIELD = LOCAT I ON_NAME : BIN 

FIELD = LOCAT I ON_C I T Y_S TATE : BIN 

FIELD = PRI ZE_NAME : BIN 

FIELD = SCORE : LONG 
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FIELD = SCORE DATE TIME 



LONG 



TABLE = W_LEADERBOARDJRANKING 

FIELD = RECORD_ID : LONG 

FIELD = LEADE RB OARD_ I D : LONG 

FIELD = RANK : SHORT 

FIELD = SUBSCRIBER ID : LONG 



TABLE = W_LOCAL_LEADERBOARD 

FIELD = RECORD_ID : LONG 

FIELD = LEADERBOARD__ID : LONG 
FIELD - LEADERBOARD_DATE_TIME : LONG 

FIELD = MAX_LEADERS : SHORT 

TABLE = W_LOCAL LEADER 

FIELD = RECORD_ID : LONG 

FIELD = LEADERBOARD_ID : LONG 

FIELD = RANK : SHORT 

FIELD = SUBSCRIBER_ID : LONG 

FIELD = ALIAS : BIN 

FIELD = SCORE : LONG 

FIELD = SCORE_DATE_TIME : LONG 

TABLE = W_LOYALTY_POINT_AWARDS 

FIELD = RECORD_ID : LONG 

FIELD = SUBSCRIBER_ID : LONG 

FIELD = LOYALTY_PROGRAM_ID : LONG 

FIELD = POINTS_AWARDED : SHORT 

FIELD = AWARD_DATE_T I ME : LONG 

TABLE = W_QUEUE 

FIELD = REC0RD_ID : LONG 

FIELD = TERMINAL_ID : BIN 

FIELD = AGE : SHORT 

FIELD = QUEUEJTIME : LONG 

FIELD = EVENT_TYPE : BIN 

FIELD = EVENT_DATA_SIZE : SHORT 

FIELD = EVENT_DATA : VARBIN 

TABLE = W_REDEMPTION_HISTORY 

FIELD = RECORD_ID : LONG 

FIELD = REDEMPT I ON__I D : LONG 

FIELD = TIME STAMP : LONG 

FIELD = SCORE : LONG 

FIELD = PAR_LEVEL_PAID : BIN 

FIELD = SUBSCRIBER^ID : LONG 

FIELD = CASH AMOUNT PAID : LONG 



TABLE = W REDEMPTION LOCAL POOL 
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FIELD = RECORD_ID 
FIELD = REDEMPT I ON_I D 
FIELD = LOCAL POOL VALUE 



LONG 
LONG 
LONG 



TABLE = W_REDEMPTION_PAR_LEVEL 
FIELD = RECORD_ID 
FIELD = REDEMP T I ON_I D 
FIELD = PAR_LEVEL 
FIELD = ADJUSTED PAR SCORE 



LONG 
LONG 
BIN 
LONG 



TABLE = W_SERVICE_ACCESSES 
FIELD = RECORD_ID 
FIELD = SERVICE_ID 
FIELD = PROFILE 
FIELD = S T ART_DATE_T IME 
FIELD = END_DATE_T IME 
FIELD = SUBSCRIBER_ID 
FIELD = CASH_FUNDS_USED 
FIELD = ACCOUNT FUNDS USED 



LONG 

LONG 

BIN 

LONG 

LONG 

LONG 

LONG 

LONG 



TABLE = W_S ERV I CE_LE ADERBOARD 
FIELD = RECORD_ID 
FIELD = SERVICE_ID 
FIELD = PROFILE 
FIELD = LEADERBOARD ID 



LONG 
LONG 
BIN 
LONG 



TABLE = W_TOURNAMENT_LOCAL_POOL 

FIELD = RECORD_ID : LONG 

FIELD = TOURNAMENT_ID : LONG 

FIELD = LOCAL POOL VALUE : LONG 



1 
1 
1 



PK 
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I claim: 

1. A system for controlling a medium of exchange 

comprising: 

(a) plural terminals at various locations for 
detecting the presence of a person and of an activity 
carried out by the person, and for providing signals 
indicative of the identity of the person and of the 
activity, 

(b) a first database for storing predetermined 
exchange values for the activity, 

(c) a second database for storing separate medium 
of exchange accounts for various persons including at 
least one of customers and merchants, 

(d) apparatus for detecting said signals, for 
accessing the first database and for crediting an 
exchange value related to the activity to an account of 
a person carrying out the activity or on whose behalf 
the activity was carried out, in the second database, 
and 

(e) an administration terminal in communication 
with the first database for generating and downloading 
to the first database parameters indicative of the 
predetermined exchange values for various activities, 
from time to time* 

2. A system as defined in claim 1 in which the 

terminals are comprised of a person identifier for 
detecting an identity of a person, and a display, 
apparatus for accessing the second database to 
determine a medium of exchange balance for an 
identified person and for causing display of the 
balance on the display, apparatus generating a 
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redemption signal relating to redemption of an exchange 
value for a product or service, and for decrementing 
the account of the identified person in the second 
database by the value of the redemption exchange value. 

3. A system as defined in claim 2, in which the 
person identifier is a reader of an identity indication 
carrier comprised of at least one of a bar code reader, 
a printed identity code reader, a magnetic strip 
reader, a smart card reader, or a voice recognizer, an 
eye iris reader, a fingerprint reader, a palmprint 
reader and a keyed identity code reader. 

4. A system as defined in claim 3 in which the 
display is comprised of a video display of at least one 
of a public computer, a computer game terminal and a 
validation terminal . 

5. A system as defined in claim 3 including plural 
displays located in proximity to each other. 

6. A system as defined in claim 3 including at 
least one electronic games, each associated with a 
display, the game or games and displays being coupled 
in a network, a memory coupled to the network for 
storing a plurality of advertisements, a database 
coupled to the network for storing control parameters 
for the advertisements, and apparatus responsive to the 
control parameters for controlling display of any of 
the advertisements on any of the displays. 

7. A system as defined in claim 5, including 
plural electronic games, each associated with a 
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display, the games and displays being coupled in a 
network, the database also for storing game parameters, 
and apparatus responsive to the game parameters for 
controlling operation of various ones of the games. 



electronic games, each associated with a display, the 
games and displays being coupled in a network, the 
database also for storing game parameters, and 
apparatus responsive to the game parameters for 
controlling operation of various ones of the games, the 
game parameters being related to at least one of speed 
of games, speed of tokens comprising the games, 
characteristics of tokens comprising the games, point 
values achievable for operation of the games, 
algorithms used for operation by the games, and medium 
of exchange values to be awarded to a player of games 
for play or achievement in playing games. 

9. A system as defined in claim 6, including 
apparatus for providing at least one of advertisement 
and game parameters from an administration terminal. 

10. A system as defined in claim 9 including a 
regional server for receiving at least one of the game 
and exchange value parameters from the administrative 
terminal, for storing said parameters in a regional 
server and for downloading particular ones of said 
parameters relating to the games and advertisements 
located at the arcade, to the database located at the 
arcade . 



8. 



A system as defined in claim 6 including plural 
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11. A system as defined in claim 10 # in which the 
parameters relating to display of advertisements are 
contained in a matrix which correlates sequences of 
predetermined advertisements to be displayed in the 
absence of or the detection of the presence of a 
detected identity of a particular person or class of 
person, content of the matrix being stored in the 
regional server . 

12. A system as defined in claim 11, in which the 
medium of exchange accounts are stored in the regional 
server. 

13. A system as defined in claim 11, further 
including plural regional servers, and a support server 
in communication with the plural regional servers for 
storing a master copy of the exchange accounts and said 
parameters, for providing to regional databases in 
communication with the regional servers, those 
parameters and exchange accounts which relate to 
arcades and terminals associated with the respective 
regional servers. 

14. A system as defined in claim 1, in which the 
plural terminals are comprised of point of sale 
terminals . 

15. A system as defined in claim 1, including 
apparatus for storing data relating to demographics of 
persons which may be identified by the terminals, 
apparatus for generating an offer based on detecting 
the presence of an identified person at a terminal and 
the demographics of that person, and apparatus for 



SUBSTITUTE SHEET (RULE 26) 



INSDOC1D: <WO_0038089A2_L> 



WO 00/38089 




PCT/CA99/01201 



108 

displaying the offer at a terminal adjacent to which 
the person has been identified. 

16. A system as defined in claim 15/ including 
apparatus for presenting the offer on one of a video 
display and a printed ticket. 

17. A system as defined in claim 15, including 
apparatus for detecting activities undertaken by the 
identified person and updating the demographic data 
accordingly. 

18. A system as defined in claim 17, including 
apparatus for updating the demographic data on a real- 
time basis. 

19. A system for controlling a medium of exchange 
comprising: 

(a) terminals for determining the presence of a 
person, and of an activity carried out by the person, 

(b) display apparatus located adjacent to the 
terminal, 

(c) a regional server in communication with the 
terminals and display apparatus, 

(d) a first database accessible by the regional 
server, 

(e) a support server in communication with the 
regional server, 

(f) an administration terminal on which control 
parameters can be input, 

(g) apparatus for receiving control parameters 
relating to medium of exchange values for activities 
carried out by the person from the administration 
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terminal and for downloading the control parameters to 
the support server, 

(h) apparatus for transferring those control 
parameters which relate to media of exchange functions 
controlled by the regional server, to the first 
database, 

(i) apparatus for transferring those control 
parameters which relate to functions carried out at the 
display apparatus and the terminals, from the first 
database to control apparatus for the display 
apparatus , 

whereby the presence and activity of said person can 
be determined and messages can be controlled to be 
presented on the display apparatus directed to the 
identified person of class of person, and exchange 
values credited to the person* 

20. A system as defined in claim 19, including 
apparatus for requesting updated parameters from time 
to time by the control apparatus for the display 
apparatus from the regional server, for comparing 
parameters at the control apparatus with those stored 
in the first database, and for updating the control 
parameters at either one of the first database and the 
control apparatus for the display apparatus. 

21. A system as defined in claim 20, including 
apparatus for storing at at least one of person 
accounts, merchant accounts and demographic data 
relating to persons in the first database, and means 
for automatically updating the person accounts, 
merchant accounts and demographic data from the 
terminals from time to time. 



SUBSTITUTE SHEET (RULE 26) 



WO 00/38089 



© 



PCT/CA99/01201 



110 

22. A system as defined in claim 21 including means 
for gathering activity information relating to a person 
from the terminals and under control of said control 
parameters, storing the activity information at the 
control apparatus for the display apparatus, whereby 
the at least one of the person accounts, merchant 
accounts and demographic data in the first database can 
be updated from time to time. 

23. A system as defined in claim 19, including 
receiving various control parameters at the 
administrative terminal from plural remote 
administrative terminals for provision to the support 
servers . 

24. A system as defined in claim 8 in which loyalty 
points form the medium of exchange. 

25. A system for controlling a medium of exchange 
comprising: 

(a) plural terminals at various locations for 
detecting the presence of a person and of an activity 
carried out by the person, and for providing signals 
indicative of at least the activity, 

(b) a first database for storing predetermined 
demographic information related to the activity, 

(c) apparatus for detecting said signals, for 
accessing the first database and for storing data 
related to the activity in a record related to a class 
of persons carrying out the activity, in the second 
database, 

(d) an administration terminal in communication 
with the first database for receiving the stored data, 
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and for generating and downloading to the first 
database parameters controlling the provision of offers 
to persons of the same class from time to time. 



26. A system for controlling a medium of exchange 

comprising: 

(a) plural terminals at various locations for 
detecting the presence of a person and of an activity 
carried out by the person, and for providing signals 
indicative of at least the activity, 

(b) a first database for storing predetermined 
demographic information related to the activity, 

(c) apparatus for detecting said signals, for 
accessing the first database and for storing data 
related to the activity in a record related to a class 
of persons carrying out the activity, in the second 
database, 

(d) an administration terminal in communication 
with the first database for receiving the stored data, 
and for generating and downloading to the first 
database parameters for controlling the provision of 
advertising for display on display apparatus which is 
part of the terminal or is adjacent the terminal, to 
the person or to persons of the same class, or for 
controlling the printing of premiums on a printer which 
is part of the terminal or is adjacent the terminal, 
from time to time. 
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(57) Abstract 

A system for controlling a medium of exchange comprising: plural terminals at various locations for detecting the presence of a 
person and of an activity carried out by the person, and for providing signals indicative of the identity of the person and of the activity, 
a first database for storing predetermined exchange values for the activity, a second database for storing separate medium of exchange 
accounts for various persons including at least one of customers and merchants, apparatus for detecting the signals, for accessing the first 
database and for crediting an exchange value related to the activity to an account of a person carrying out the activity or on whose behalf 
the activity was carried out, in the second database, and an administration terminal in communication with the first database for generating 
and downloading to the first database parameters indicative of the predetermined exchange values for various activities, from time to time. 
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